Category: Certification

Advantages of ISO/IEC 27701:2019 certification

Posted on by admin

Privacy Information Management System (PIMS) standard called ISO/IEC 27701 was created to assist organisations in adhering to privacy legislation all over the world. Numerous nations have passed new data protection legislation in recent years that specify the conditions for safeguarding and handling personally identifiable information (PII). However, it isn’t always obvious how businesses should abide by these rules. The 2019 release of ISO 27701 offers organisations practical advice to help them comply with these many rules.

The information security management system (ISMS) standard ISO/IEC 27001 has been expanded with ISO/IEC 27701:2019. ISO/IEC 27701 focuses primarily on protecting personal data, while ISO/IEC 27001 establishes a standard for secure IT governance in the broadest sense. The first international standard of its kind, ISO/IEC 27701, is applicable to both public and private businesses, as well as to governmental and non-profit organisations. It encourages adherence to all other regions’ personal data governance regulations as well as the GDPR in the EU.

How Come ISO 27701 Certification Is Essential? 

National governments and organisations like the EU have enacted stringent new legislation regarding private data privacy in the wake of several high-profile data breaches. The PII of citizens, including names, residences, age, bank account information, and more, are protected by these data protection regulations. However, it might be very difficult to comprehend how to apply these standards to your organization’s ISMS. Additionally, it is difficult and time-consuming for organisations to ensure compliance with the data governance requirements of numerous nations when processing customer and employee data across multiple jurisdictions. You are supported by ISO/IEC 27701, which offers a standardized method of adhering to all of these laws.

Following are some advantages of ISO 27701 certification:

  • Clarification of the roles and responsibilities of PII controllers and processors as well as adherence to all pertinent data protection legislation.
  • Increase stakeholder trust in your privacy and data protection procedures and gain a competitive edge with ISO/IEC 27701 certification.
  • To fulfil the requirements of international data governance regulations, achieve world-class standards through a strict risk- and compliance-driven strategy.
  • Increase openness by employing thorough security and privacy controls to track and report data privacy advances.
  • Reduce PII-related risk by monitoring changing privacy risks and the regulatory environment.
  • Demonstrate that you adhere to PII protection requirements around the world, supporting business ties with your customers and suppliers.

Read more about this: 10 Essential Requirements of GDPR Summarized.

How ISO 27701 Eases Compliance With Other Privacy Standards?

Posted on by admin

In the data dependent world today, organizations across the globe are dealing with Personal Data in some extent or another. The increasing number of sensitive data sharing services and platforms have raised concerns around Personal Data and Personal Identifiable data to a great extent. Private Data protection is an immediate need, especially for organizations that act as PII controllers / Fiduciaries and/or PII Processors.

To address this need, Regulatory bodies across the globe have introduced significant data privacy legislation/regulation to protect the Data Subjects / PII Principals. The privacy specific ISO 27701:2019 standard, GDPR, California Consumer Privacy Act and Philippines Data Protection Act are a few to name.

While going through these multiple privacy regulations across various countries, its clear that the emphasis is more towards the expectations from Data Processors and/or Data controls of Personal Data. These acts/ regulations state about what the organization is supposed follow to avoid any penalties and consequences in case of any breach or non-compliance to the legislations. The regulations guide everyone on how to meet those expectations in terms of Protection of the Personal data and supporting rights of data owners etc.

ISO 27701:2019 – Extension of the renowned ISO 27001:2013

ISO 27701 specifies the requirements, providing guidance for establishing, implementing, and maintaining a privacy management system for information. The standard is an extension to ISO/IEC 27001 and ISO/IEC 27002.

As PII controllers and PII processors hold major responsibility and accountability while managing the PII, the standard stated privacy requirements apply to all size organizations that process PII within the scope of ISMS. The clear guidance helps organizations to establish, implement, and maintain the Privacy framework within their system, helping them with the data protection measures.

The PIMS’s Clauses 5 through 8 are drafted specially for the data protection program.

Clause 5 – Data Protection: Addresses every clause in ISO 27001 and identifying organization’s status to recognize the need for data protection, considering the organization’s role in relation to PII as a controller or processor.

Clause 6: PIMS-specific guidance on ISO 27002 controls: Establishes a top-level amendment for ‘information security’ that needs to be included under privacy, having significantly impact on data protection.

Clause 7: Additional guidance for PII controllers: Guidance on ISO 27701’s Annex A controls that address critical areas of data protection and privacy that are not accounted for by the controls provided in ISO 27001.

Clause 8: Additional guidance for PII processors: Guidance on ISO 27701’s Annex B controls addressing critical areas of data protection and privacy that are not accounted for by the controls provided in ISO 27001.

The implementation guidance and key references stated in ISO 27701 touches base with the elements to identify:

  1. Impact assessment (like the kind of data the organization is collecting or processing)
  2. Location of the data storage (comprising of the locations impacting the data),
  3. Transfer of data takes place between any other parties or processing companies.

To understand these data elements better, the organization can depend on its internal Data Flows, Process mapping documents and more.

Meeting compliance with GDPR, CCPA, CPL

The robust guidelines and requirements stated in the ISO 27701, helps any organization implementing to come certainly halfway in meeting any other privacy legislations and regulations without much hassle. ISO 27701 provides basic requirements and guidance for the following aspects of

  1. Conditions for Collection and Processing of Personal Data
  2. Obligations towards Data Owners/ PII Principals
  3. How to implement Privacy by design and Privacy by default
  4. Conditions applied for Data Sharing, Transfer and Disclosure

Mapping with GDPR:

ISO 27701 Annex D, provides an indicative mapping between the requirements of GDPR and the controls stated under PIMS, indicating how fulfilling compliance as per ISO 27701 can help fulfil multiple obligations of GDPR as well.

Mapping to ISO/IEC 29100 :

Annex C of the PIMS provides an indicative mapping between provisions of this document and the privacy principles from ISO/IEC 29100

Key Differences between multiple privacy standards

The main difference between various Privacy regulations/ Legislation and 27701 is that this regulation only focusses on What to do, whereas 27701 focuses on How to do.

ISO 27701 is an auditable standard that complies with these requirements for generating evidence of how the organization processes the personal data. Some interesting topic while dealing with multiple privacy standards are:

  1. Anonymization vs Pseudonymization
  2. Data Controller vs Data Processor
  3. Data Subject Access Request (DSAR)
  4. “Don’t Sell My Information” on the website — Requirement of CCPA
  5. Backup Policy for PII
  6. Supervisory Authority of Member Countries

Similar affirmations hold importance while facilitating the agreements with all the stakeholders like Regulatory Bodies, End Users, Consumers, Clients and whomsoever it is relevant to.

For global organizations planning to implement privacy controls, ISO 27701 can be the best approach for build a baseline, even if the organizations are bound by other laws and legislations. The prime focus should be to have stringent policies and process in place to prevent fines owing to data breach or non-compliance with the data protection regulations.

As ISMS is the prime requirement to build your information security management, investing in international privacy standard like PIMS (ISO 27701) will certainly have a positive impact in long term.

How To Transition From PA DSS To PCI SSF: A Guide – Part 2

Posted on by admin
Contd from  How To Transition From PA DSS To PCI SSF: A Guide – Part 1
 
Understand PCI SSF framework
Organizations must comprehend the subtleties of the new structure in order to take appropriate action. It will be easier for your company to take the appropriate actions and restructure your business operations and related activities if you are aware of how the new framework functions and how it can affect your firm. Therefore, before making any choices or taking any activities related to the PCI SSF transition, we strongly advise enterprises to read the PCI Council document in its entirety.
 
Conduct a Gap Analysis 
The organisation should execute a gap analysis to determine where they stand in relation to the new PCI SSF criteria as the next logical step, which is what we anticipate them to do. This will provide the company with a clear path for putting safeguards into place or revising its processes, policies, and procedures to comply with the PCI SSF Standard.
 
Recognize the Differences Between PCI SSF and PCI SLC
Two distinct and independent projects make up the PCI Security Standard Framework, each of which has its own set of standards, validation standards, and SSC listing. Secure Software Lifecycle Program (SSL) and Secure Software Standard are the two initiatives (SSS).
Both programme concentrate on various facets of software security. For vendors to assess how they can manage the security of payment software while establishing or implementing security standards and procedures as necessary based on their business, it is essential that they understand the differences. In this approach, companies can be verified for SSL and a different SSS for payment software that has been built according on software eligibility requirements. Understanding the distinctions between Secure Software Lifecycle Program (SSL) and Secure Software
 
Get in touch with a qualified expert
For technical advice and assistance in planning for the transition phase scheduled to begin in 2022, organisations should speak with an experienced specialist. They will be in a better position to comprehend the new regulations and assist firms in translating the needs to achieve PCI SSF compliance because they are seasoned specialists in the field.
In order to assist enterprises in implementing measures and ensuring a seamless transition for the organisation, QRC is well-equipped to do so. Organizations can use our team of experts’ assistance to find and close gaps in compliance with PCI SSF standard requirements.
 
Keep track of the PCI Council’s most recent PCI SSF revisions.
Organizations must, of course, continuously monitor any announcements or most recent modifications made by the PCI Council regarding PCI SSF. By doing this, the business will make sure that everything is set up and ready to update its policies, practises, and workflows in order to meet the PCI SSF Standard by October 2022.
 
Conclusion 
Organizations may appear uncertain about and even struggle with the change from PA DSS to PCI SSF. However, if they adhere to the rules, the transition period may not have much of an influence on compliance efforts. Actually, the PCI SSF was created to aid software developers and provide them the freedom to plan and create payment application security in accordance with industry best practises and standards.
Additionally, PCI Council has taken all necessary steps to ensure a smooth transition, including the endeavor to keep the PCI SSF and PA-DSS Programs running concurrently until their expiration dates. So, in order to ensure a smooth transition, we firmly advise enterprises to embrace the PCI SSF initiative rather than running away from it.
 
You can get in touch with our specialists at QRC Assurance for any questions or advice on PCI SSF and the processes to start the transition from PA DSS to PCI SSF. Our experts would be more than delighted to assist you in achieving compliance and to make the process simple for you.

How To Transition From PA DSS To PCI SSF: A Guide – Part 1

Posted on by admin
The Payment Application Data Security Standard was introduced in 2008 to help software developers create safe payment applications for businesses and service providers. It is a standard that was devised and created for all software development companies producing software applications that store, process, or send sensitive authentication information as well as cardholder data. In order to raise the security requirements for applications that handle payments, the Payment Card Industry Security Standard Council recently unveiled a new architecture. The PA-DSS Standards would gradually be phased out by 2022 due to the adoption of the new Standards. After talking about this in greater detail, we’ve provided some advice for the organisation wanting to make the move from PA DSS to PCI SSF as painless as possible. However, let’s first comprehend that.
 
What Is PCI SSF?
To protect the design and development of payment application software, the PCI Software Security Framework is a new application security standard. The PCI Council took measures to raise the security requirements for payment applications and provide clients with secure and dependable online payment services. The standard was created to help software development suppliers construct a safe application by implementing best practises in order to adapt to the changing security and threat landscape.
 
The new framework enables a modern approach to application design and development that works with conventional payment software. Additionally, it aids in the development and upkeep of payment software that safeguards sensitive data, payment transactions, and overall exposure to risks. Adhering to the new standard verifies the security of the software.
 
Goals of the New PCI Software Security Framework
Traditional and contemporary software security criteria are combined in the PCI Program Security Framework to enable new technologies, software kinds, and development techniques. The new standard also aids suppliers in fortifying their defences against the new threats by reacting to the changing threat landscape. In order to enable both the conventional approaches to effective application security and the most recent development techniques, the software security framework was created with an emphasis on security practises.
 
What organisations need to be aware of in relation to the change from PA-DSS to PCI SSF
With expanded criteria that accommodate a range of payment software types, technologies, and development methodologies, PCI SSF replaces PA-DSS. The new Standard won’t have an impact on the current payment application within the PCI environment, despite the fact that PA-DSS Standards will phase out in October 2022. The standard will be available and fully supported during the transition time to prevent interruption and make the transition process easier for enterprises. The PCI Council’s schedule, which is provided below, should help organisations understand how PA-DSS will eventually be phased down in October 2022.
Before making any decisions, businesses should consider the following additional factors that the council has identified as being crucial.
  • Applications that have already been PA-DSS validated will continue to appear on the list of Validated Payment Applications until their expiration dates.
  • Vendors have until the end of October 2022 to submit revisions in accordance with standard procedure.
  • The PA-DSS Program will, however, end at that point, and all PA-DSS validated payment apps will be relocated to the “Acceptable Only for Pre-Existing Deployments” page on the list of Validated Payment Applications.
  • The deadline for new payment application submissions for PA-DSS validation is this month’s 30th of June 2021, after which the validation will expire.
  • Vendors can start the validation process for their Software Lifecycle Management processes and payment software once SSF Assessors are certified and listed on the PCI SSC website.
  • Both Validated Payment Software and Secure SLC Qualified Vendors will be included on the PCI SSC website.
  • On the PCI SSC List of Validated Payment Software, payment software that has been verified as conforming to the Secure Software Standard will be listed. When PA-DSS expires at the end of October 2022, the list will take the place of the present list of Validated Payment Applications.
  • The SSF also contains a PCI SSC List of Secure SLC Qualified Vendors, which lists companies that sell payment processing software and whose software lifecycle development procedures have been approved as satisfying the Secure SLC Standard.
Here are some actions that enterprises should take to achieve a seamless transition from PA DSS to PCI SSF while keeping everything in mind. 
How should PCI SSC stakeholders get ready for this change? Read Here

Overview of Various PCI SSC Security Standards

Posted on by admin

PCI SSC maintains various PCI standards, supporting programs, and related documentation. PCI Security Standards are developed specifically to protect payment account data throughout the payment lifecycle.

  1. PCI DSS (Payment Card Industry Data Security Standard) : PCI DSS covers security of the environments that store, process, or transmit account data. The scope of PCI DSS covers environments receiving account data from payment applications and other sources—acquirers. Generally applicable for merchants, Service Providers, any payment solution providers.
  2. PCI Secure Software Standard ( 3S) : The Secure Software Standard defines a set of security requirements to help ensure payment software adequately protects the integrity and confidentiality of payment transactions and data. The Secure Software Standard includes a set of “core” requirements that apply to all types of payment software submitted for validation under the PCI Software Security Framework, regardless of the software’s functionality or underlying technology. Generally applicable for Payment Software vendors who would like to sell their Payment Software to their customers as a off the shelf-product.
  3. PCI Secure Software Lifecycle: The PCI Secure Software Lifecycle (Secure SLC) Requirements provides a baseline and guidance to help payment software design, develop, and maintain secure payment software throughout the software lifecycle. Generally applicable for Software Development vendors who would like to develop payment software on behalf of their customers.
  4. PCI 3DS ( Three Domain Secure): This standard helps the entities who perform the 3DS Server (3DSS), 3DS Directory Server (DS), 3DS Access Control Server (ACS) Functions.   3DS is a messaging protocol that enables end users to do a multi factor authentication themselves with their card issuer when making any online purchases / E-commerce Transactions. Generally applicable for Acquirers (Merchant Banks) and Issuers (Cardholders Bank).
  5. PA DSS (Payment Application Data Security Standard): PCI PA-DSS covers secure payment applications to support PCI DSS compliance. The scope of PA-DSS addresses when a payment application receives account data from cardholder-interface devices such as point-of-sale terminals or other devices and begins the payment transaction. However PA-DSS is replaced by PCI Software Security Framework. Generally applicable for Payment Application vendors who would like to sell their application as a off the shelf product.
  6. PCI PTS – POI (Payment Card Industry PIN Transaction Security Point of Interaction): The PCI PTS – POI standard covers device tamper detection, cryptographic processes, and other mechanisms used to protect the PIN and other sensitive data, such as cryptographic keys. Generally applicable for Device Manufacturers.
  7. PCI PTS – PIN ( Payment Card Industry PIN Transaction Security – Personal Identification Number: The PCI PTS – PIN standard covers secure management, processing and transmission of personal identification number (PIN) data during online and offline payment card transaction processing. Generally applicable for Device Manufacturers.
  8. PCI PTS – HSM ( Payment Card Industry PIN Transaction Security – Hardware Security Module): The PCI PTS – HSM standard covers the design of hardware security modules and for securely protecting those devices until they are deployed. Generally applicable for HSM Device Manufacturers.
  9. PCI P2PE (Payment Card Industry Point-to-Point Encryption) : PCI P2PE (Point-to-Point Encryption) covers secure encryption, decryption, and key management for point-to-point encryption solutions. Requirements for a P2PE solution will vary depending on the deployment environment and the technologies used for a specific implementation. Generally applicable for the service providers who are providing end to end encryption solutions for their merchants.
  10. PCI Contactless Payments on COTS ( CPoC): The PCI Contactless Payments on COTS (CPoC) Solutions enable contactless payment acceptance on a merchant’s consumer device using an embedded (near-field communications) NFC interface. This listing is a resource for merchants and acquirers to use in selecting a Contactless Payments on COTS (CPoC) Solutions. Generally applicable for PIN on Mobile Solution providers.
  11. PCI Software-Based PIN Entry on COTS (SPoC) : Also famous as PIN on mobile device. This Standard provides requirements for developing secure solutions that enable EMV contact and contactless transactions with PIN entry on the mobile devices of consumers using a secure PIN entry application in combination with a Secure Card Reader for PIN (SCRP). Generally applicable for PIN on Mobile Solution providers.

Stay Tuned, for more information and updates on payment security !!

Understanding HIPAA Rules In Brief

Posted on by admin

HIPAA provides guidance for the proper uses and disclosures of protected health information (PHI), how to secure PHI, and the response activities in case there is a breach. The HIPAA rules and regulations consists of five major components

  • HIPAA Security Rule
  • HIPAA Privacy Rule
  • HIPAA Omnibus Rule
  • HIPAA Breach Notification Rule
  • HIPAA Enforcement Rule

A summary of these Rules is discussed below.

HIPAA Security Rule:
The HIPAA Security Rule establishes national standards to protect individuals’ electronic personal health information that is created, received, used, or maintained by a covered entity. The Security Rule requires appropriate technical, physical and administrative safeguards to ensure the confidentiality, integrity, and security of electronic protected health information.

Technical Safeguards

Technical Safeguards concern the technology that is used to protect ePHI and provide access to the data. The only stipulation is that ePHI – whether at rest or in transit, it must be encrypted once it travels beyond an organization´s internal firewalled servers. This is so that any breach of confidential patient data renders the data unreadable, undecipherable, and unusable. Thereafter organizations are free to select whichever mechanisms are most appropriate to:

Physical Safeguards

Physical Safeguards focus on physical access to ePHI irrespective of its location. ePHI could be stored in a remote data center, in the cloud, or on servers which are located within the premises of the HIPAA covered entity. They also stipulate how workstations and mobile devices should be secured against unauthorized access:

HIPAA Administrative Safeguards

The Administrative Safeguards are the policies and procedures which bring the Privacy Rule and the Security Rule together. They are the pivotal elements of a HIPAA compliance checklist and require that a Security Officer and a Privacy Officer be assigned to put the measures in place to protect ePHI, while they also govern the conduct of the workforce.

HIPAA Privacy Rule

  • The HIPAA Privacy Rule governs how ePHI can be used and disclosed. In force since 2003, the Privacy Rule applies to all healthcare organizations, the providers of health plans (including employers), healthcare clearing houses and – from 2013 – the Business Associates of covered entities.
  • The Privacy Rule demands that appropriate safeguards are implemented to protect the privacy of Personal Health Information. It also sets limits and conditions on the use and disclosure of that information without patient authorization. The Rule also gives patients – or their nominated representatives – rights over their health information including the right to obtain a copy of their health records – or examine them – and the ability to request corrections if necessary.
  • Under the Privacy Rule, covered entities are required to respond to patient access requests within 30 days. Notices of Privacy Practices (NPPs) must also be issued to advise patients and plan members of the circumstances under which their data will be used or shared.

HIPAA Omnibus Rule:

HHS enacted the  final Omnibus Rule  in 2013 to address policy gaps in earlier HIPAA rules. Most notably, the Omnibus Rule defines the role of business associates, which were not previously subject to HIPAA rules, and outlines the criteria for Business Associate Agreements (BAAs) which must be executed between organizations sharing PHI before any information is transferred, handled, or maintained.

HIPAA Breach Notification Rule

The HIPAA Breach Notification Rule requires covered entities to notify patients when there is a breach of their ePHI. The Breach Notification Rule also requires entities to promptly notify the Department of Health and Human Services of such a breach of ePHI and issue a notice to the media if the breach affects more than five hundred patients.

There is also a requirement to report smaller breaches – those affecting fewer than 500 individuals – via the OCR web portal. These smaller breach reports should ideally be made once the initial investigation has been conducted. The OCR only requires these reports to be made annually.

Breach notifications should include the following information:

  • The  nature of the ePHI involved, including the types of personal identifiers exposed.
  • The unauthorized person who used the ePHI  or to whom the disclosure was made (if known).
  • Whether the ePHI was actually  acquired or viewed  (if known).
  • The extent to which the  risk of damage has been mitigated.

HIPAA Enforcement Rule

HIPAA Enforcement Rule governs the investigations that follow a breach of ePHI, the penalties that could be imposed on covered entities responsible for an avoidable breach of ePHI and the procedures for hearings. Although not part of a HIPAA compliance checklist, covered entities should be aware of the following penalties:

  • A violation attributable to ignorance can attract a fine of $100 – $50,000.
  • A violation which occurred despite reasonable vigilance can attract a fine of $1,000 – $50,000.
  • A violation due to willful neglect which is corrected within thirty days will attract a fine of between $10,000 and $50,000.
  • A violation due to willful neglect which is not corrected within thirty days will attract the maximum fine of $50,000.
  • Fines are imposed per violation category and reflect the number of records exposed in a breach, risk posed by the exposure of that data and the level of negligence involved.
  • Penalties can easily reach the maximum fine of $1,500,000 per year, per violation category. It should also be noted that the penalties for willful neglect can also lead to criminal charges being filed.
  • Civil lawsuits for damages can also be filed by victims of a breach.

The organizations most commonly subject to enforcement action are private medical practices (solo doctors or dentists, group practices, and so on), hospitals,  outpatient facilities such as pain clinics or rehabilitation centers, insurance groups, and pharmacies.

Need more insights ?  Get in touch  with our experts for any queries on HIPAA Assessment and Compliance.

What does HIPAA Risk Assessment covers

Posted on by admin

All risk assessments, HIPAA – related policies and reasons why addressable safeguards have not been implemented must be chronicled in case a breach of PHI occurs and an investigation takes place to establish how the breach happened. Each of the HIPAA requirements is explained in further detail below. Business unsure of their obligation to comply with the HIPAA requirements should seek professional advice.

What should a Risk Assessment consist of?

Throughout the HIPAA regulations, there is a lack of guidance about what a HIPAA risk assessment should consist of. OCR explains the failure to provide a “specific risk analysis methodology” is due to Covered Entities and Business Associates being of different sizes, capabilities, and complexity.

However, OCR does provide guidance on the objectives of a HIPAA risk assessment:

  1. Identify the PHI that your organization creates, receives, stores and transmits – including PHI shared with consultants, vendors and Business Associates.
  2. Identify the human, natural and environmental threats to the integrity of PHI – human threats including those which are both intentional and unintentional.
  3. Assess what measures are in place to protect against threats to the integrity of PHI, and the likelihood of a “reasonably anticipated” breach occurring.
  4. Determine the potential impact of a PHI breach and assign each potential occurrence a risk level based on the average of the assigned likelihood and impact levels.
  5. Document the findings and implement measures, procedures, and policies where necessary to tick the boxes on the HIPAA compliance checklist and ensure HIPAA compliance.
  6. The HIPAA risk assessment, the rationale for the measures, procedures and policies subsequently implemented, and all policy documents must be kept for a minimum of six years.

As mentioned above, a HIPAA risk assessment is not a one-time requirement, but a regular task necessary to ensure continued compliance. The HIPAA risk assessment and an analysis of its findings will help organizations to comply with many other areas on our HIPAA compliance checklist and should be reviewed regularly when changes to the workforce, work practices or technology occur.

Depending on the size, capability, and complexity of a Covered Entity, compiling a fully comprehensive HIPAA risk assessment can be an extremely long-winded task. There are various online tools that can help organizations with the compilation of a HIPAA risk assessment although, due to the lack of a “specific risk analysis methodology”, there is no “one-size-fits-all solution.

The OCR pilot audits identified risk assessments as the major area of Security Rule non-compliance. Risk assessments are going to be checked thoroughly in the second phase of the audits not just to make sure that the organization in question has conducted one, but to ensure they are comprehensive and ongoing. A risk assessment is not a one-time requirement, but a regular task necessary to ensure continued compliance.

The difference between the “required” safeguards and the “addressable” safeguards on the HIPAA compliance checklist is that “required” safeguards must be implemented whereas there is a certain amount of flexibility with “addressable” safeguards. If it is not reasonable to implement an “addressable” safeguard as it appears on the HIPAA compliance checklist, covered entities have the option of introducing an appropriate alternative, or not introducing the safeguard at all.

That decision will depend on factors such as the entity’s risk analysis, risk mitigation strategy and what other security measures are already in place. The decision must be documented in writing and include the factors that were considered, as well as the results of the risk assessment, on which the decision was based.

GDPR : Who does it Cover and Requirements ?

Posted on by admin
This article is part of our GDPR compliance consultancy services hub page, designed to help businesses understand GDPR scope, applicability, and compliance requirements. In this blog, we explain who GDPR applies to, which organizations need to comply, and the key requirements for protecting personal data when handling information of individuals covered under the regulation.

On May 25, 2018, the EU’s 1995 Data Protection Directive and all member state laws based on it were replaced by the GDPR (General Data Protection Regulation), a pan-European data protection regulation. The GDPR introduces a 21st-century approach to data protection with its significant and extensive scope. It gives people more control over how their personal data is gathered and processed and gives organisations (both controllers and processors) several additional requirements to be more accountable for data protection. The Data Protection Act of 2018 in Ireland, which took effect on May 25, 2018, complies with the GDPR’s limited chances for member states to create provisions or derogations for how the Regulation applies in their nation.

Who is covered by the GDPR?
  • Even if they are not EU citizens, all EU organisations that gather, store, or otherwise process the personal data of people who reside in the EU.
  • Companies situated outside of the EU that provide goods or services to residents there, observe their behaviour, or handle their personal data.
GDPR requirements are:
1. Accountability and Governance
You must be able to demonstrate compliance with the GDPR. This includes:
  • creating a system for governance with jobs and duties.
  • keeping thorough records of each and every data processing operation.
  • preserving policies and practises for data protection.
  • conducting DPIAs (data protection impact assessments) for processing procedures that pose a high risk.
  • putting in place the necessary safeguards to protect personal data.
  • training for staff members’ awareness.
  • appointing a data protection officer as necessary.
2. The six data processing principles
Six data processing principles are outlined in the GDPR and must be followed by data controllers. Personal information must be:
  • Processed lawfully, fairly and transparently.
  • Collected only for specific legitimate purposes.
  • Adequate, relevant and limited to what is necessary.
  • Accurate and, where necessary, kept up to date.
  • Stored only as long as is necessary.
  • Processed in a manner that ensures appropriate security.
3. Lawful processing
Personal data can only be treated in the following ways, with the exception of particular categories of data, which cannot be processed except in certain circumstances:
  • If the data subject has given their consent
  • To meet contractual obligations
  • To comply with legal obligations
  • To protect the data subject’s vital interests
  • For tasks in the public interest
  • For the legitimate interests of the organisation
4. Data subjects’ rights
Data subjects have:
  • The right to be informed
  • The right of access
  • The right to rectification
  • The right to erasure
  • The right to restrict processing
  • The right to data portability
  • The right to object and
  • Rights concerning automated decision-making and profiling.
5. Valid consent
There are stricter rules regarding consent:
  • Freely granted, specific, informed, and unambiguous consent is required.
  • A request for consent must be understandable and written in unambiguous terms.
  • Consent will no longer be accepted in the form of inaction, pre-ticked boxes, or silence.
  • Anytime can be used to revoke consent.
  • Only with parental approval is a child’s internet service consent legitimate.
  • Organizations are required to provide proof of permission.
6. Data protection by design and by default
Data controllers and processors are required to put in place organisational and technical measures that are intended to effectively apply the data processing principles.
  • The processing should incorporate the necessary safeguards.
  • Any new procedure, system, or technological advancement must take data protection into account during the design phase.
  • An essential component of privacy by design is a DPIA (data protection impact assessment).
7. Transparency and privacy notices
Organizations must be transparent about how, why, and who will process personal data.
  • Data controllers are required to give data subjects a privacy notice when collecting personal information directly from them.
  • Data controllers shall deliver a privacy notice without undue delay and within a month where personal data is not collected directly from data subjects. The first time they speak with the data subject, they must do this.
  • Data controllers must decide how the data subjects will be informed for all processing activities and then write privacy notices accordingly. Notices may be given out gradually.
  • Data subjects must get privacy notices in a clear, visible, and easily available format using plain English.
8. Data transfers outside the EU
After the transition period is through, many non-EU organisations that process the personal data of EU citizens must also appoint an EU representative.
  • When a nation has been recognized by the EU as offering a sufficient level of data protection
  • through standard contractual provisions or legally binding business practices
  • by adhering to an accepted certification procedure.
9. Mandatory data breach notification
A breach of security that results in the unintentional or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data that is transmitted, stored, or otherwise processed is referred to as a personal data breach under the GDPR.
  • All breaches of personal data must be reported to data controllers by data processors.
  • If there is a threat to the rights and freedoms of data subjects, data controllers are obligated to notify breaches to the supervisory authority (the Data Protection Commission (DPC) in Ireland) within 72 hours of becoming aware of them.
  • If there is a significant risk to the rights and freedoms of the data subjects, they must be informed without undue delay.
10. DPOs (data protection officers)
You must be able to show that the GDPR is being followed. This comprises:
  • establishing a system for governance with positions and duties
  • maintaining a thorough log of all data processing activities
  • maintaining policies and practises for data protection
  • performing DPIAs (data protection impact assessments) for processing processes that pose a high risk
  • putting in place the necessary safeguards to protect personal data
  • whenever necessary, conducting staff awareness training and establishing a data protection officer

Understanding Various Levels Of Merchants Service Provider

Posted on by admin

Any Merchant and Service provider Reporting a PCI DSS Compliance by two different validation methods:

  1. Self-Assessment Questionnaire (SAQ)
  1. SAQ is a validation tool for merchants and service providers to report the results of their PCI DSS self-assessment, if they are not required to submit ROC
  2. Includes a series of yes-or-no questions for each applicable PCI DSS requirement
  3. Different SAQs available to meet different merchant environments.

B. Onsite Assessment by Qualified Security Assessor

  1. Onsite assessment is a validation mechanism for merchants and service providers by a Qualified Security Assessor (QSA)
  2. QSA submits the Report on Compliance (ROC) and attestation Of Compliance (AOC)
  3. QSA and authorized  person at merchant/service provider entity require to sign the AOC
  1. How to identify what applies to your organization? SAQ or Onsite Assessment?
  1. If you are a merchant, depends on your annual transactions per year across all channels, payment card brands defined four levels.
  2. If you are a service provider, depends on your annual transactions per year across all channels, payment card brands defined two levels.
  3. All levels, except Level 1, must complete a self-assessment questionnaire as well as have a quarterly external vulnerability scan using an Approved Scanning Vendor (ASV).
  1. Merchants PCI Compliance Levels:

Definition of Merchant: The entity directly provide service and/or Product to the End customer and get the Money through various channels. Examples like Hotels, Restaurants, Airlines, Hospitals, Online Shopping Portals etc.,

Note: Depends on the Type of SAQ Applicable for your organization, there is a need of performing Internal Vulnerability scans and Penetration testing. Read our Blog on Type of SAQ’s.

  1. Service Providers PCI Compliance Levels:

Definition of Service Provider: Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of other entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples like Hosting Service Providers, Card Printing Services, Backup Services Providers, Managed Service Providers, Security Management, Contact Centres and/or Back office Processing companies etc.,

Receiving a Report on Compliance (ROC) and validating as a Level 1 Service Provider allows entities to be on Visa’s Global Registry of Approved Service Providers. Which will help the entities recognized  as a Trusted service provider and useful for Pitching for the new business opportunities.

Guide to ISO/IEC 27701:2019 Clauses

Posted on by admin

The worldwide standard for a privacy information management system is ISO/IEC 27701. (PIMS). It is a privacy addition to ISO/IEC 27002 Security Controls and ISO/IEC 27001 Information Security Management.

These are some particular organisational roles:

  • PII controllers (among them are those who act as joint PII controllers)
  • PII processors

Following are the clauses mentioned in ISO 27701:

Clause 1: Scope

In here, the prerequisites for the management system’s intended use are outlined. As an addition to ISO/IEC 27001 and ISO/IEC 27002, ISO/IEC 27701 aims to provide rules and recommendations for setting up, implementing, maintaining, and improving a privacy information management system. focused on the individuals who are in charge of and accountable for handling PII, including PII controllers and PII processors.

Clause 2: Normative references

Documents cited in a standard are considered normative references. These include: ISO/IEC 27000 Overview and vocabulary for information security management systems ISO/IEC 27001 Information security management systems: requirements The ISO/IEC 27002 Code of Practice for Information Security Controls Framework for privacy established by ISO/IEC 29100

Clause 3: Terms and definitions

Important terminology used throughout the standard that are not defined in ISO/IEC 27000 and ISO/IEC 29100 are given a few extra definitions in this section.

Clause 4: General

In relation to ISO/IEC 27701, this clause “sets the scene.” It gives a high-level overview of the document’s organisation and identifies where the PIMS-specific requirements are located in reference to ISO/IEC 27001 and ISO/IEC 27002.

Clause 5: PIMS specific requirements related to ISO/IEC 27001

The purpose of this clause is to incorporate the protection of privacy into the information security criteria of ISO/IEC 27001 as well.

Determine your function as a processor and/or controller within the framework of the company, and take into account the influence of internal and external elements including privacy-specific rules and contractual requirements. Depending on your function, you must implement and apply the pertinent controls from Annexes A and/or B to your current statement of applicability.

Additionally, you must take into account the parties with an interest in the processing of PII, the scope of your PIMS, and the efficient implementation, upkeep, and ongoing improvement of the system. To ensure the protection of privacy, consideration and extension of ISO/IEC 27001’s requirements for management, planning, support, operation, performance evaluation, and improvement must be taken into account. Risks to information and processing of PII must now be evaluated and handled carefully, in particular.

Clause 6: PIMS specific guidance related to ISO/IEC 27002

This clause aims to expand ISO/IEC 27002’s information security recommendations to include privacy protection.

For instance, based on compliance, contractual, and stakeholder needs, enterprises need to take into account the extra implementation guidance regarding information security policies to incorporate pertinent privacy declarations.

Roles and duties in respect to the processing of PII are described with greater clarity. This includes being informed of incident reporting requirements and the repercussions of a privacy violation.

Advice is provided to guarantee that PII is taken into account while classifying your information. You must be aware of the PII your company handles, where it is kept, and the systems it passes through. Additionally, people need to know what PII is and how to spot it.

On incident management, removable media, user access on PII processing systems and services, cryptographic protection, reassigning PII storage space, back-up and recovery of PII, event log reviews, information transfer policies, and confidentiality agreements, more thorough implementation guidance is provided.

Additionally, this clause’s instructions encourage you to take PII into account before transmitting data over open networks and as part of the system’s development and design. Relationships with suppliers as well as their expectations and obligations must be addressed.

Clause 7: Additional guidance for PII controllers

This section deals with PIMS-specific implementation advice for PII controllers. It is associated with the measures detailed in Annex A.

For instance, in order to be in compliance with the laws that apply, you must specify the precise purposes for the PII you process and have a legal justification for doing so. If the intent behind processing PII evolves or expands, updates should be made.

Aside from these topics, the guidance also outlines contracts with PII processors, clear roles and responsibilities with any joint controllers, considerations of special category data and consent requirements, privacy impact assessment requirements to reduce risk to PII principals, and considerations of special category data and considerations.

People whose PII you process should understand why and how information is processed, along with a point of contact for inquiries. On consent, withdrawals, and PII access, correction, or deletion, specific instructions are provided. Additionally offered are third-party obligations, managing requests, and automated decision-making advice.

The accuracy and quality of PII, constraints on the amount collected based on the purpose of processing, and end of processing criteria should all be taken into account when implementing privacy by design for processes and systems. Importantly, PII sharing, transfer, and disclosure information is provided to assist you in moving your records between jurisdictions.

Clause 8: Additional guidance for PII Processors

This section addresses implementation advice for PII processors particular to PIMS. The restrictions indicated in Annex B are relevant.

For instance, in order to help customers meet their obligations, including those of PII principles, customer contracts should mention your company’s function as a PII Processor. To utilise PII data for marketing and advertising, prior consent is required.

There is advice provided on how to locate and keep track of the records required to prove compliance with the agreed-upon PII processing you carry out.

Detailed instructions are provided on how to assist your customer with specific requests, manage temporary files created during processing, return, transfer, or securely dispose of PII, and use the proper transmission controls.

In order to accommodate jurisdictional transfers, third-party and subcontractor requirements, and management of legally enforceable PII disclosures, thorough PII sharing, transfer, and disclosure guidance is provided.

Annexes

The ISO/IEC 27701 standard contains a number of Annexes. While annexes C–F contain additional information that can help with setting up and running an effective PIMS, annexes A and B are for controllers and processors, respectively. Following are covered in Annexes:

Annex A

An inventory of PII controller controls. A reason for any control that is excluded must be included in the statement of applicability even though not all controls will be necessary.

Annex B

An inventory of PII processor controls. A reason for any control that is excluded must be included in the statement of applicability even though not all controls will be necessary.

Annex C

Controls for PII controllers are mapped to the privacy principles in ISO/IEC 2900. This illustrates how compliance with ISO/IEC 27701’s requirements and controls relate to the privacy principles in ISO/IEC 29100.

Annex D

Articles 5 to 49 of the GDPR are mapped to the provisions in ISO/IEC 27701 (except 43). This demonstrates how fulfilling GDPR regulations might be relevant to conforming to ISO/IEC 27701 requirements and controls.

Annex E

Clauses in ISO/IEC 27701 mapped to:

  • Requirements for PII processors in public clouds under ISO/IEC 27018
  • ISO/IEC 29151 for guidelines and extra controls for PII controllers.

Annex F

Provides information on how to apply ISO/IEC 27701 to ISO/IEC 27001 and ISO/IEC 27002. It offers various application examples as well as a clear map of how information security words are extended to encompass privacy.