PCI DSS

PCI DSS is a set of requirements outlined by the PCI Council for securing the processing, transmission, and storage of payment data by the merchants and third-party service providers.
PCI DSS is a data security standard, and not a regulation enforced by law. However, compliance to the standard is mandated by the contracts signed by the merchants with the card brands (Visa, MasterCard, etc.) and with the banks that handle their payment processing.
PCI non-compliance can result in penalties ranging from $5,000 to $100,000 per month by the credit card companies. The penalties levied depend on the volume of clients, the volume of transactions, the merchant level of PCI-DSS, and the time or duration for non-compliance.
Yes. Outsourcing services or using third-party services will not exclude a company from PCI DSS compliance. Although, outsourcing to the third-party will reduce the risk exposure and consequently reduce the efforts to validate compliance. But the company cannot completely ignore PCI DSS Compliance.
Generally, small merchants or service providers who are not required to provide Compliance reports but wish to demonstrate their efforts towards securing sensitive data use SAQ for validation. SAQ is a self-validation tool and a merchant’s statement of PCI Compliance. It contains a series of questions relating to the 12 requirements of the PCI DSS Compliance with options of “Yes and No” that need to be answered by the merchants.For questions that are answered as “No,” an attached remediation plan describing actions it plans to take to resolve the issue are required.
An Attestation of Compliance is a document of declaration to be attached with SAQ that states the merchant’s eligibility to perform and have performed the appropriate Self-Assessment.

Merchants who fall in the scope of PCI Compliance will most likely fall in one of the four merchant levels, based on the transaction volume over 12 months. The transaction volume is based on the aggregate number of Visa transactions which is inclusive of credit, debit, and prepaid from a merchant “Doing Business As” (DBA). In cases where a merchant has more than one DBA, Visa acquirers should consider an aggregate volume of transactions stored, processed, or transmitted to determine the validation level.

Level 1

Criteria:

Merchants processing more than 6 million Visa, Mastercard, or Discover transactions annually via any channel.
Merchants processing more than 2.5 million American Express transactions annually.
Merchants processing more than 1 million JCB transactions annually.
Merchants that have suffered a data breach or cyberattack resulting in cardholder data being compromised.
Merchants that have been identified by another card issuer as Level 1.

Level 2

Criteria:

Merchants processing between 1 million and 6 million Visa, Mastercard, or Discover transactions per year via any channel.
Merchants processing between 50,000 to 2.5 million American Express transactions annually.
Merchants processing less than 1 million JCB transactions annually.

Level 3

Criteria:

Merchants processing between 20,000 and 1 million Visa e-commerce transactions annually.
Merchants processing 20,000 MasterCard e-commerce transactions annually, but less than or equal to 1 million total MasterCard transactions annually.
Merchants that process 20,000 to 1 million discover card-not-present only transactions annually.
Less than 50,000 American Express transactions.

Level 4

Criteria:

Merchants processing less than 20,000 Visa or MasterCard e-commerce transactions annually.
All other merchants processing up to 1 million Visa or MasterCard transactions annually.

Level 1 validation requirements

Annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA)
Quarterly network scan by Approved Scan Vendor (ASV)
Attestation of Compliance Form

Level 2 validation requirements

Annual Self-Assessment Questionnaire (SAQ)
Quarterly network scan by Approved Scan Vendor (ASV)
Attestation of Compliance Form

Level 3 validation requirements

Annual Self-Assessment Questionnaire (SAQ)
Quarterly network scan by Approved Scan Vendor (ASV)
Attestation of Compliance Form

Level 4 validation requirements

Depends on the requirements of the merchant’s acquiring bank.
Annual Self-Assessment Questionnaire (SAQ)
Quarterly network scan by Approved Scan Vendor (ASV)

CCPA

The California Consumer Privacy Act, (CCPA) is a data privacy law developed in 2018 to protect the personal information of California residents.
CCPA goes into effect on January 1st, 2020.
Personal Information refers to information that identifies, relates to, describes, and is linked to or associated with a consumer or household. This may include name, address, social security number, email address, search history, IP address, or geolocation data to name a few.
Personal Information that is publicly available information that is sourced from federal, state, or local government records, such as professional licenses and public real estate/property records are exempted under CCPA.
Under CCPA, each business has 30 days to cure violations and inform consumers that they have done so. After these 30 days, if the business still does not comply, it can be fined anywhere between $2,500 to $7,500. The business may also have to pay $100 to $750 per consumer per incident after a civil action.

The California Consumer Privacy Act of 2018 (CCPA) gives consumers more control over the use of Personal Information collected by the business. It is a law that secures new privacy rights for California consumers which includes-

Right to notice
Right to access
Right to opt-out or right to opt-in
Right to request deletion
Right to equal services and prices.
Businesses can sell the Personal Information of a child under the age of 16 if they get affirmative authorization with an opt-in from the child. But, for children under the age of 13, the opt-in must come from the child’s parent or guardian.

GDPR

The General Data Protection Regulation is an EU data protection law that applies across the EU with the same authority as if it were a member state law.

Data subjects have the following rights relating to their personal data

Right to be Informed
Right of Access
Right to Rectification
Right to Erasure
Right to Restrict Processing
Right to data portability
Right to object
Rights concerning automated decision-making and profiling.
The GDPR defines personal data as any information relating to an identified or identifiable person known as a data subject. This could be any person identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier, or information specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.
The GDPR defines breach of Personal Data as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed.
Non-compliance to GDPR results in fines up to €20 million or 4% of global revenue, whichever is higher. Data protection authorities can also issue sanctions, such as bans on data processing or public reprimands.
A Data Protection Officer (DPO) is the one responsible for ensuring GDPR compliance in the organization. The DPO is the main point of contact for the data protection authority.
When the UK leaves the EU, the EU GDPR will no longer directly apply. However, its requirements will still be part of UK law as the UK Data Protection Act 2018 shall replace with the GDPR’s requirements for areas outside the Regulation’s scope.

HIPAA

Any healthcare entity be it healthcare service providers, health planners, and healthcare clearinghouses that electronically process, store, transmit, or receives medical records, claims or remittances must comply with HIPAA law.
Information that relates to the health condition of an individual and that either identifies the individual or there is a basis to believe that the information can be used to identify, locate, or contact the individual can be called as Protected Health Information.
Any business entity that falls in the scope of HIPAA Compliance and is expected to comply with the regulations may be called as a covered entity. This would typically include healthcare providers, insurance companies, and clearinghouses.
Non-Compliance to HIPAA Regulation can result in fines up to $250,000 for violations or even imprisonment up to 10 years for knowing abuse or misuse of health information.
Any device or electronic equipment that collects, stores, or transmits PHI will fall in the scope of HIPAA. This would even include medical devices, wearable, and IoMT (Internet of Medical Things) devices that have in-built microprocessors and features WiFi/Bluetooth that can store PHI data and also transmits it to the cloud and accessed by the healthcare entity.
A Fitbit used for personal use does not fall in the scope of HIPAA, but a Fitbit which is a part of a corporate wellness program would fall in the scope of HIPAA Regulation.
No. The Privacy Rule does not apply to de-identified information since it neither identifies nor provides a reasonable basis to identify an individual.

ISO20000 Certification

ISO 20000 is an international standard designed for IT Service Management. It is a framework against which the organization can measure its service manage the system and works as a guide to delivering quality services to the business and its customers.
ISO 20000 applies to any organization that wishes to implement procedures and processes to provide quality service and enhance the effectiveness of its IT services.
While ISO 20000 provides a standard framework, ITIL outlines the best practices to manage the IT process in your organization. ITIL focuses on aligning your IT services with the wider scope and needs of your business.
Organizations looking to be certified against ISO 20000 will need to be assessed by a Registered Certification Body (RCB). The audit involves 2 stages wherein stage 1 audit helps determine the organization’s readiness for ISO 20000 certification and provides a list of identified non-conformities. This would in turn help you with correcting any issues in preparation for the final stage 2 audit. In stage 2 of the audit, the auditor assesses compliance with the ISO 20000 requirements and on successful compliance, the organization gets certified against ISO 20000.
The audit conducted is to verify if the organization fulfills the requirements of ISO/IEC 20000, Part 1 of Service Management System Requirements. So, typically in the audit process, the organization needs to prove how the audit was fulfilled with relevant evidence. The evidence to be presented should be in the form of documents wherein the auditor will verify if they are fit for documented processes, as per service management policies and as required by ISO 20000. The auditor will also hold interviews with the staff of your organization to check if everyone is familiar with the processes and the documented processes are adhered to.
Time taken for ISO 20000 will depend on many factors including the type and size of the organization. Moreover, if organizations have previously been certified against other management standards will definitely have a clear advantage. However, in general, an organization may most likely spend 1 or 2 years preparing for the certification audit.

ISO27001

ISO27001 is an international standard for Information Security Management. The certification ensures the effectiveness of security controls and ensures all policies are in place. It provides a framework for organizations to follow and manage their information securely.
ISO 27001 standards is a framework designed to protect the sensitive data of an organization. So, any organization that has sensitive information, be it profit or non-profit, small business, government, or private sector organization can benefit from ISO 27001 Certification.
ISO 27001 provides a standard framework for organizations to manage their information security and risk exposure. So, organizations looking to strengthen their information security controls and systems will require an ISO27001 certification. The certification works as an assurance for clients and enhances the reliability and security of systems and information. This also helps improve customer and business partner confidence.
The key difference between ISO 27001 and ISO 27002 is that ISO 27002 is designed for reference when selecting security controls within the process of implementing an Information Security Management System based on ISO 27001. Another key difference is that organizations can achieve certification to ISO 27001 but not for ISO 27002.
ISO27001 Standard comprises of 114 controls divided into 14 categories.

ISO 27001 controls are divided into 14 categories which include

Annex A.5 – Information security policies (2 controls)
Annex A.6 – Organisation of information security (7 controls)
Annex A.7 – Human resource security (6 controls)
Annex A.8 – Asset management (10 controls)
Annex A.9 – Access control (14 controls)
Annex A.10 – Cryptography (2 controls)
Annex A.11 – Physical and environmental security
Annex A.12 – Operations security (14 controls)
Annex A.13 – Communications security (7 controls)
Annex A.14 – System acquisition, development, and maintenance (13 controls)
Annex A.15 – Supplier relationships (5 controls)
Annex A.16 – Information security incident management (7 controls)
Annex A.17 – Information security aspects of business continuity management (4 controls)
Annex A.18 – Compliance (8 controls)
Although implementing ISO 27001 standards for information security controls is considered to be the industry best practice they are not mandatory for compliance. This is mainly because the Standard recognizes that every organization will have its own requirements when developing ISMS and that not all controls may be applicable.

MAS TRM

The Monetary Authority of Singapore is the Central Bank and the Financial Regulatory Authority of Singapore. It administers the various statutes pertaining to money, banking, insurance, securities, and the financial sector in general.
Technology Risk Management is a set of guidelines outlined by the Monetary Authority of Singapore to encourage the adoption of industry best practices for the management of technology risk.
The Monetary Authority of Singapore set out Technology Risk Management guidelines to guide Financial Institutes to establish a robust technology risk management solution, strengthen system security, and safeguard sensitive data and transactions.

MAS Technology Risk Management Guidelines set out technology risk management principles and statement of best practices for the financial sector, to guide FIs in the following:

Establish Sound and Robust Technology Risk Governance and Oversight
Maintain Cyber Resilience

MAS TRM Compliance focuses on the following area-

Governance
User authentication
Cyber hygiene
Encryption
Anti-fraud

The MAS has introduced 7 key amendments in the MAS TRM guidelines which are as follows

1) Expanded roles and responsibilities for the Board of Directors and Senior Management.
2) Assessment or evaluation of vendors
3) Assessment of the third party in connecting to Application Programming Interface (APIs) and governing third party’s API access.
4) Cyber Threat Monitoring and Information Sharing
5) Cyber Incident Response and Management
6) Cyber Security Assessments
7) Simulation of cyber-attacks tactics, techniques, and procedures
Institutions are expected and hence encouraged to implement all the risk management practices outlined in the TRM guidelines for outsourcing arrangements involving a MAS-regulated entity. The extent and degree to which an institution should implement the risk management practices shall depend on the nature of risks and the materiality of the outsourcing arrangement. The framework used by the institution to evaluate the risks of such outsourcing arrangement requires to be approved by the Board of Directors of the Institute, or delegated committee by the Board of Directors.

NESA

The National Electronic Security Authority (NESA) is the UAE’S federal authority. They are responsible for the advancement of cybersecurity across the nation.
For protecting the UAE’s critical data information infrastructure and improve the national cybersecurity, NESA introduced the UAE Information Assurance Standards (UAE IAS). Compliance with the set standards is mandatory for all organizations identified as critical infrastructure to UAE.
The National Electronic Security Authority (NESA) formed on June 25, 2014, made the declaration about important security policies and standards to align with UAE National cyber-security efforts. The announcement came after a meeting between key members of UAE federal and local entities who were part of the ‘National Cyber Security Program

NESA Compliance is mandatory for:

Government organizations
Semi-government organizations
Any Business organizations that are identified as UAE’s critical infrastructure.

NESA’s UAE IAS regulations were created with the aim to:

Strengthen the security of UAE cyber assets and reduce corresponding risk levels
Protect critical infrastructure
Improve cybersecurity threat awareness in the UAE
Develop human capital and technical capabilities
The UAE’s IAS Standard includes 188 security controls and standards which are all grouped into different categories based on priority. Ranging from P1 which is of the highest priority to P4 which is of the lowest priority. NESA created a list of security controls based on 24 threats that were compiled from various industry reports.
Management Control Family Controls Technical control families Controls
M1: Strategy and Planning 15 T1: Asset management 10
M2:  Information Security Risk Management 11 T2: Physical & environmental security 16
M3: Awareness and Training 8 T3: Operations management 17
M4: Human Resource Security 8 T4: Communications 15
M5: Compliance 13 T5: Access control 22
M6: Performance Evaluation & Improvement 5 T6: Third-party security 6
    T7: Information systems acquisition, development, and maintenance 25
    T8: Information security incident management 13
    T9: Information security continuity management 4

PA DSS

Whether PA-DSS is mandatory or not it is determined by the Payment brands.
Payment applications that are sold distributed or licensed to third-parties software vendors are subject to the PA-DSS requirements.
Payment applications that are developed for self-use or sold to only one customer are not subject to the PA-DSS requirements. However, the application must be covered by that customer’s PCI DSS assessment.
Payment applications that are developed in-house by merchants or service providers and are not sold to a third party are not subject to the PA-DSS requirements.
Payment applications that are resident in standalone point-of-sale terminals are not subject to the PA-DSS requirements provided
The terminals have no connection to any of the merchant’s systems or networks.
The terminals connect only to the merchant’s acquirer or processor via a private line.
The payment application vendor provides secure remote updates, troubleshooting, access, and maintenance.
Sensitive authentication data is never stored after authorization
Secure payment applications facilitate a customer’s PCI DSS compliance. PA-DSS validated payment applications will minimize the potential of security breaches leading to compromises of full magnetic stripe data, card validation codes and values (CAV2, CID, CVC2, and CVV2), PINs, and PIN blocks.
PA-DSS Assessment can only be performed by a qualified and trained PA-QSA by PCI SSC. However, it is important to note that not all QSAs are qualified as a PA-QSAs. A PA-QSA requires additional qualification and is required to specifically apply and be qualified by PCI SSC.
Technically speaking the requirements for Payment Application Data Security Standard (PA-DSS) is derived from the Payment Card Industry Data Security Standard (PCI DSS). PCI DSS details what a payment application must support to facilitate a customer’s PCI DSS compliance. In general PCI DSS compliance may not apply to payment application vendors they do not store, process, or transmit cardholder data. However, the payment applications are used by customers to store, process, and transmit cardholder data, which is why payment applications should facilitate PCI DSS compliance.

PCI PIN

PCI PIN is a security requirement and a standard outlined for merchants that accept, process, or transmit payment card personal identification numbers (PIN). The PIN Security requirements are set by the Payment Card Industry Security Standards Council (PCI SSC) and outlined in the PCI PIN Security Documents and Procedures.
The purpose of a PCI PIN Assessment is to assess whether or not the organization is securely managing, processing, and transmitting PIN data during online and offline payment card transactions. The Assessment involves encryption, key management of PIN transactions, and secure management of processing equipment. This would also involve assessing the POS devices and the hardware security module (HSM) used to decrypt the PIN and to manage the keys. Right from the chain–processing the PIN to managing keys used to protect the PIN is a part of the PCI PIN Assessment scope.

The PCI PIN Assessment is for:

Companies performing activities in the PIN transaction process such as

Acquiring (including ISOs)
Processing
Storage
Transmission

Companies that provide encryption management services such as:

o Key-injection facilities (KIFs)
o Certificate and registration authorities (CAs and RAs)

Other entities may fall into scope if directed by a participating payment brand to perform a PIN Assessment.

PCI PIN Assessments are done every 2 years.
PCI PIN Assessments start at around $50,000, but the cost largely depends on consulting time necessary to prepare for the PIN assessment and the number of locations that need to be assessed.

Pen Test

Penetration Test which is also known as the “Pen Test” is a process of evaluating the security of systems or networks by simulating an attack by ethical hackers. The test involves active exploitation and analysis of the system for any potential vulnerabilities that could result in poor system configuration, security flaws, or operational weaknesses.
The initial step in penetration testing involves familiarizing with company operations & the scope of work to create an accurate proposal. It would then involve gathering relevant for a better assessment. However, this stage of information gathering largely depends on the type of Pen Test opted by the requester. Clients may seek a Blackbox approach where little information is provided while simulating a real-world attack and response. In this scenario, we still grasp the size/complexity for efficient testing.
Penetration testing is applicable for multiple compliance standards including PCI, HIPAA, SOC2, and others. That said, every compliance standard is different and so it should be discussed before moving forward.
While automated tools are initially used in the process, a large majority of the testing is performed manually. The amount of automated and manual work varies depending from project-to-project, but around 80-90% of the penetration test is done manually.
The time taken for Penetration tests depends on multiple factors. So, typically see projects going from one week to multiple weeks or even months.
Penetration testing costs can vary significantly depending on the various factors. Scoping details such as network IP addresses, complexity and number of applications, and employees for social engineering are key factors to determining project size. However, the cost typically starts at $10,000 and can grow into even six-digit figures for large and, in-depth projects.

SOC1 SOC2 SOC3 Audit and Attestation Reports

A SOC 1 Audit is focused on the internal controls related to financial reporting (ICFR). While a SOC 2 Audit is focused on information and IT security based on 5 Trust Services Principles namely Security, Confidentiality, Privacy, Processing Integrity, and Availability.
A SOC 1 Type 1 report is an attestation of controls at a service organization at a specific point in time. Whereas a SOC 1 Type II, report is an attestation of controls at a service organization over a minimum six-month period.
SOC 2 Type 1 report details the suitability of the design controls of the service organization’s system. It details the system at a point in time particularly its scope, the management of the organization describing the system, and the controls in place. While SOC 2 Type 2 report is an internal controls report detailing the effectiveness of security controls and its operations that safeguards customer data.
The SOC 3 report is a public report of internal controls of a service organization, based on the 5 TSP Security, Availability, Processing Integrity, Privacy, and Confidentiality. It details the same information as in the SOC2 Report but is designed in a way to meet the needs of users who require assurance about the controls at a service organization.
SOC1 Report provided by an independent auditor is intended to assure the effectiveness of internal controls over financial reporting over the outsourced services. SOC2 Report provided by an independent auditor is intended to provide assurances about the effectiveness of controls in place at a service organization concerning the Security, Availability, Privacy Confidentiality, and Processing integrity of systems processing clients' information. SOC3 report details the outcome of a SOC2 Audit which concerns the effectiveness of controls at a service organization. Since SOC2 reports are confidential and used for an internal purpose, SOC3 reports are designed and made publicly available to provide assurance to customers and other stakeholders the effectiveness of internal controls.

SOC 1 reports and SOC 2 reports are not public or general use documents. They are for the internal use of service organization and limited in their distribution. However, the SOC3 report can be made available to the public for providing the stakeholder the assurance about the service organizations internal controls.

Vulnerability Assessment

Vulnerability is a weakness or flaws in a system that allows an attacker to compromise the confidentiality, integrity, or availability of the system or data.
Vulnerability Test or Vulnerability Assessment is a process that evaluates systems to detect/identify security loopholes or vulnerabilities in the infrastructure.
Vulnerability Assessment is a process of identifying, prioritize and remediate security weaknesses in systems. It is an evaluation process performed under the following circumstances.
Before a new system or application goes live
When a current system or application is replaced or upgraded
As and when the system or application’s remote access requirements or user base changes
After previously identified vulnerabilities are remedied
Vulnerability Assessment typically consists of 1-2 weeks of scanning followed by 1-2 weeks of analysis and report preparation which takes another 1-2 weeks.
Remediation of all the vulnerabilities detected and stated in the report is the responsibility of the requester and their project team. The requester is further expected to document his remediation efforts.
Remediate vulnerabilities stated in the report.
Resolution table in the VA report must be completed for each vulnerability regardless of whether the Vulnerability has been remedied or not.
Vulnerabilities that are remedied must be tested to ensure appropriate application functionality.
Communicate that all servers and applications in the scope of Vulnerability Assessment are closed with no work pending while the retest takes place.
When remediation is complete a Risk Letter is drafted with the list of vulnerabilities remedied and the vulnerabilities that will not be remedied. This is approved by the director of ITS and the department head requesting the VA.