Advantages of ISO/IEC 27701:2019 certification

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?

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

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.

PCI Secure SLC vs PCI Secure Software

The Payment Card Industry Software Security Framework, introduced by PCI SSC, is a relatively new framework that will go into effect in October 2022. The PCI SSF is a collection of various codes and tools created to safeguard payment software. It’s a framework that was created to take the position of the Payment Application Data Security Standard (PA-DSS) with more up-to-date standards that support various payment software types, technologies, and development techniques. The framework gives software developers the freedom to combine payment application security with the most up-to-date industry-best SDLC practices and frequent update cycles.
The Secure Software Lifecycle (SLC) Standard and the Secure Software Standard make up the framework. The eligibility requirements determine which standard is used. For a better understanding of the framework, the details of both standards are provided below.

What is a Secure Software Standard?

The PCI Secure Software Standard (PCI SSS) is a set of rules that Payment Software Vendors had to comply with in order to be recognized by the PCI Security Standard Council as a Validated Payment Software or Listed Payment Software. Validating the payment software guarantees that the application is developed securely and in accordance with the best practices and standards available. The validation ensures that the Payment Software was created securely to safeguard both the software’s integrity and the privacy of any sensitive data it saves, processes, or transfers.
Validation and listing are required for payment software created by the vendor that is intended to support or assist payment transactions in terms of processing, transmitting, or storing payment data, as well as software that is commercially accessible for sale to various organisations. On the PCI SSC website, there is a list of all the validated payment software that has been identified and listed.

What is the Secure Software Lifecycle standard?

A standard called the PCI Secure Software Lifecycle (SLC) was created with the aim of guaranteeing the security of the software vendor’s software development process, methodology, and practices . The ability to build secure payment software is demonstrated by comparing the organization’s software lifecycle management procedures to the Secure SLC Standard. By constructing a solid defense against attacks, this increases the assurance that the payment software is secure for supporting all types of payment transactions while also lowering risk exposure or vulnerabilities. Overall, the testing of the vendor’s SLC procedures, technology, and design, development, and maintenance of the payment software throughout the course of the whole software lifecycle establishes the level of security of the system against the PCI SLC.

Difference between PCI Secure Software Standard (SSS) and PCI Secure Software Lifecycle (SLC)

Under the Payment Software Security Framework, there are two distinct programme called Secure Software Standard (SSS) and Secure Software Lifecycle (SLC) (PCI SSF). Both curricula concentrate on various facets of software security verification. The PCI SSS evaluates the overall efficacy of the security of the programme whereas the SLC verifies the security policies and procedures used in software design and development. As a result, businesses may be verified for both the Secure Software Lifecycle for their software development process and the Secure Software Standard for any created payment software. Only software developers that create Payment Software that is sold, distributed, or licensed to third parties are subject to the PCI SSS.
This could include payment software that is installed on customers’ computers or that is intended for their use, regardless of how the programme is provided. In contrast, PCI Secure SLC is applicable to all software vendors who want to verify and guarantee the security of their Payment Software solutions. Software suppliers should be aware that if they have already been verified for SSS, they do not necessarily need to be validated against Secure SLC. Secure SLC validation, however, can make it simpler to maintain the validation of the payment programme when modifications are made to it.

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

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

PCI DSS V4.0 Core 12 Requirements – Part 2

PCI DSS 4.0 Requirement 7 –  Requirement  12 covers multiple aspects, like restriction on the cardholder data, network and user access, testing of ongoing systems and how organizations maintain their infosec policy.

Requirement 7 : Restrict Access to System Components and Cardholder Data by Business Need to Know

  • Organizations needs to establish a robust Processes and mechanisms for restricting access to system components and cardholder data by business need to know are defined and understood
  • Access to system components and data is appropriately defined and assigned
  • Access to system components and data is managed via an access control system(s).

Requirement 8 : Identify Users and Authenticate Access to System Components

  1. Organizations needs to establish a robust Processes and mechanisms for identifying users and authenticating access to system components are defined and understood
  2. User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle
  3. Strong authentication for users and administrators is established and managed
  4. Organization must enforce multi-factor authentication (MFA) is implemented to secure access into the CDE
  5. Organization must enforce multi-factor authentication (MFA) systems are configured to prevent any misuse.
  6. Use of application and system accounts and associated authentication factors is strictly managed.

Requirement 9 : Restrict Physical Access to Cardholder Data

  1. Organizations needs to establish a robust Processes and mechanisms for restricting physical access to cardholder data are defined and understood.
  2. Physical access controls manage entry into facilities and systems containing cardholder data.
  3. Physical access for personnel and visitors is authorized and managed.
  4. Media with cardholder data is securely stored, accessed, distributed, and destroyed.
  5. Point of interaction (POI) devices are protected from tampering and unauthorized substitution

Requirement 10 : Log and Monitor All Access to System Components and Cardholder Data

  1. Organizations needs to establish a robust Processes and mechanisms for logging and monitoring all access to system components and cardholder data are defined and documented.
  2. Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
  3. Audit logs are protected from destruction and unauthorized modifications.
  4. Audit logs are reviewed to identify anomalies or suspicious activity.
  5. Audit log history is retained and available for analysis.
  6. Time-synchronization mechanisms support consistent time settings across all systems.
  7. Failures of critical security control systems are detected, reported, and responded to promptly.

Requirement 11 : Test Security of Systems and Networks Regularly

  1. Organizations needs to establish a robust Processes and mechanisms for regularly testing security of systems and networks are defined and understood.
  2. Wireless access points are identified and monitored, and unauthorized wireless access points are addressed.
  3. External and internal vulnerabilities are regularly identified, prioritized, and addressed
  4. External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected
  5. Network intrusions and unexpected file changes are detected and responded to.
  6. Unauthorized changes on payment pages are detected and responded to.

Requirement 12 : Support Information Security with Organizational Policies and Programs

A comprehensive information security policy that governs and provides direction for protection of the entity’s information assets is known.

  1. Acceptable use policies for end-user technologies are defined and implemented
  2. Risks to the cardholder data environment are formally identified, evaluated, and managed.
  3. PCI DSS compliance is managed
  4. PCI DSS scope is documented and validated
  5. Security awareness education is an ongoing activity
  6. Personnel are screened to reduce risks from insider threats
  7. Risk to information assets associated with third-party service provider (TPSP) relationships is managed
  8. Third-party service providers (TPSPs) support their customers’ PCI DSS compliance
  9. Suspected and confirmed security incidents that could impact the CDE are responded to immediately

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

PCI DSS v4.0 Core 12 Requirements – Part 1

The PCI  Standards Security Council (PCI SSC) published the latest update to the PCI DSS v4.0 that has significantly shifted the focus on outcome-based. requirements. The core 12 PCI DSS requirements remained unchanged fundamentally with the revised version, however they are now realigned to significantly address how the security controls should be implemented.

PCI DSS v4.0 includes a number of changes and option to implement and validate PCI DSS requirements.

Requirement 1 : Install and Maintain Network Security Controls – Such as Firewalls and any other Network security Technologies such as VPC’s, Security Groups helps the entities to control the traffic between In/Out of their network and Internal network Segments physically or logically.

  1. Organizations needs to establish a robust Processes and mechanisms for installing and maintaining network security controls should be defined and communicate with all the stakeholders.
  2. Network security controls (NSCs) should be securely configured and maintained regularly.
  3. Network access to and from the cardholder data environment is restricted with predefined rules and policies.
  4. Network connections between trusted and untrusted networks are controlled.
  5. Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.

Requirement 2 : Apply Secure Configurations to All System Components like Firewalls, Routers, Switches, Applications, Databases and any other Network security devices, End User devices etc.,

  1. Organizations needs to establish a robust Processes and mechanisms for applying secure configurations to all system components are defined and understood.
  2. System components are configured securely and managed securely.
  3. If organization using any Wireless environments, then such environments are configured and managed securely.

Requirement 3 : Protect Stored Account Data Like Card Holder Data (CHD) and Sensitive Authentication Data (CHD). Read our FAQ’s.

  1. Organizations needs to establish a robust Processes and mechanisms for protecting stored account data are defined and understood.
  2. Storage of account data is kept to a minimum as per the business and regulatory requirements.
  3. Sensitive authentication data (SAD) is not stored after authorization even if it is encrypted.
  4. Access to displays of full PAN and ability to copy cardholder data are restricted.
  5. Primary account number (PAN) is secured wherever it is stored.
  6. Cryptographic keys used to protect stored account data are secured.

Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.

Requirement 4 : Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Network.

  1. Organizations needs to establish a robust Processes and mechanisms for protecting cardholder data with strong cryptography during transmission over open, public networks are defined and documented.
  2. PAN is protected with strong cryptography during transmission.

Requirement 5 : Protect All Systems and Networks from Malicious Software like viruses, worms, Trojans, spyware, and rootkits etc.,

  1. Organizations needs to establish a robust Processes and mechanisms for protecting all systems and networks from malicious software are defined and understood.
  2. Malicious software (malware) is prevented or detected and addressed.
  3. Anti-malware mechanisms and processes are active, maintained, and monitored.
  4. Anti-phishing mechanisms protect users against phishing attacks.

Requirement 6 : Develop and Maintain Secure Systems and Software

  1. Organizations needs to establish a robust Processes and mechanisms for developing and maintaining secure systems and software are defined and understood.
  2. Bespoke and custom software are developed securely.
  3. Security vulnerabilities are identified and addressed in timely manner
  4. Public-facing web applications are protected against attacks like Man-In Middle attacks etc.,
  5. Changes to all system components are managed securely

Read about the  PCI DSS 4.0 Core 12 Requirements – Part 2, here

Overview of Various PCI SSC Security Standards

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

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

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.