Regulations & Standards, answered in plain English

The California Consumer Privacy Act (CCPA) is a law that passed in the state of California that addresses the data privacy of personal data for residents of California.

CCPA was published by the California State Legislature in September 2018.

The California Consumer Privacy Act (CCPA) became effective on January 1, 2020.

According the State of California’s Department of Justice, the CCPA applies to for-profit businesses that do business in California and meet any of the following:

Have a gross annual revenue of over $25 million

Buy, receive, or sell the personal information of 50,000 or more California residents, households, or devices; OR Derive 50% or more of their annual revenue from selling California residents’ personal information.

The CCPA does not apply to nonprofit organizations or government agencies.

A resident of California may ask businesses to:

Disclose what personal information they have about the California resident and what they do with that information.

Delete the California resident’s personal information and not sell the personal information.

Be notified, before or at the point businesses collect the California resident’s personal information, of the types of personal information they are collecting and what they may do with that information.

As stated by State of California’s Department of Justice, businesses cannot discriminate against California residents for exercising their rights under the CCPA. Businesses cannot make a California resident waive these rights, and any contract provision that says the California resident waive these rights is unenforceable.

Proposition 24 (Prop 24) modifies the California Consumer Privacy Act (CCPA) to force companies to honor consumers’ requests that their data not be shared and to get permission before collecting data on teens and children.

Prop 24 also allows consumers to opt out of personal information being used for marketing and request that incorrect information about them be corrected. Prop 24 establishes a new agency to oversee consumers’ data privacy.

Proposition 24 was passed in the November 2020 election.

Proposition 24 enhanced the California Consumer Privacy Act (CCPA) and provides consumers with additional rights for how businesses can interact with their consumer data.

Proposition 24 requires businesses to do the following:

Not share or sell a consumer’s personal information to third parties upon the consumer’s request.

Disclose whether the business collects sensitive personal information, the types of sensitive personal information collected, the purpose for which the sensitive personal information would be collected, and the length of time that the business intends to retain the sensitive personal information.

Provide consumers with an opt-out option for having their sensitive personal information used or disclosed for advertising or marketing.

Obtain permission before collecting data from consumers who are younger than 16 obtain permission from a parent or guardian before collecting data from consumers who are younger than 13.

Correct a consumer’s inaccurate personal information upon the consumer’s request The requirements listed above were in addition to the requirements under the California Consumer Privacy Act (CCPA) passed in 2018, which requires businesses to:

Disclose to the consumer the personal information that has been collected about the consumer and the commercial purpose of the information collected upon the consumer’s request.

Not sell a consumer’s personal information to third parties upon the consumer’s request.

Delete the consumer’s personal information upon the consumer’s request.

Proposition 24 defines sensitive personal information as:

Personal Information that reveals a consumer’s social security, driver’s license, state identification card, or passport number

A consumer’s account log-in, financial account, debit card number, or credit card number in combination with any required codes, passwords, or credentials allowing access to an account

A consumer’s precise geolocation

A consumer’s racial or ethnic origin, religious or philosophical beliefs, or union membership

The contents of a consumer’s mail, email and text messages (unless the business in the intended recipient of the communication).

A consumer’s genetic data.

A consumer’s biometric information (for the purpose of identifying the consumer).

Information concerning the consumer’s health.

Information concerning a consumer’s sex life or sexual orientation.

Proposition 24 exempts some types of information used for certain purposes from the consumer data requirements, including:

Vehicle information or vehicle ownership information retained or shared between vehicle dealers and manufacturers for the purpose of vehicle repairs

A consumer’s credit standing, reputation, and worthiness for the purpose of consumer reports.

Personal information collected by a business for a job application and used within the context of the consumer’s role as a job applicant, employee, or independent contractor.

Emergency contact information collected by a business and used within the context of having the information on file for emergency contact purposes.

Personal information collected by a business that is needed to administer employment benefits.

Personal information reflecting a written or verbal communication or a transaction between a business and an employee, owner, or independent contractor.

A student’s grades, educational scores, or educational test results held on behalf of a local education agency.

Proposition 24 states that the consumer data requirements cannot restrict a business’s ability to comply with federal, state, and local laws; civil, criminal, or regulatory investigations and summons; and court orders and subpoenas.

Proposition 24 allows local law enforcement agencies to direct a business to hold onto personal information for 90 days to provide law enforcement time to acquire a court-ordered subpoena, order, or warrant.

If there is a cyber security breach or insider theft issue where forensic analysis is required to find the person or data lost, the data hold period is extended from 90 days to 180 days.

The California Consumer Privacy Act (CCPA) of 2018 gave businesses 30 days to address and fix violations and data breaches before getting fined. Businesses had a 30-day grace period after discovering the breach to notify California residents who may be impacted by that data breach.

Proposition 24 maintains the 30-day requirement to address and fix violations and data breaches; however, Prop 24 removes the 30-day grace period before the company must notify California residents who may be impacted by that data breach. Companies now must immediately notify impacted California residents after discovering a breach.

Proposition 24 adopted the following penalties for violations and data breaches:

Up to $2,500 for each violation Up to $7,500 for each violation involving the information of a person under the age of 16 Up to $750 per consumer per data breach incident or actual damages, whichever is greater

Proceeds from fines and related settlements were to be deposited into a Consumer Privacy Fund, which would be used to offset costs to courts, the attorney general, and the California Privacy Protection Agency which will enforce the consumer data law.

SecureFLO can advise your organization on how to comply with CCPA and Prop 24. We will develop an approach customized for your needs to assess your organization’s risk under CCPA.

Our assessment includes analyzing your business processes and data lifecycle, and helping you manage risk from your vendors and service providers. We partner with our clients to not only identify and remediate risk but also gain compliance with applicable regulations. Achieving compliance can increase your customers’ trust in your products and services.

SecureFLO can also train your team and help them participate in implementing your organization’s cybersecurity policies and procedures.

SecureFLO services are available as subscription offerings so you can choose the right combination of services for your business and manage your budget efficiently.

The Cybersecurity Maturity Model Certification (CMMC) was developed by the U.S. Department of Defense (DoD) to certify that contractors have the controls to protect sensitive data including Federal Contract Information (FCI) and Controlled Unclassified Information (CUI).

CMMC helps ensure that companies and contractors in the defense industry (or “defense industrial base”) adopt cybersecurity best practices. CMMC provides a certification of trust about the cybersecurity policies and procedures the companies and contractors have in place to protect their data and data that they may share with third parties.

The U.S. Department of Defense recently announced that contractors who provide products and services for the defense supply chain will be required to comply with the Cybersecurity Maturity Model Certification (CMMC) process beginning in 2020.

Contractors to the defense industry should begin taking immediate steps to:

1. Clearly document practices and procedures with those requirements that already comply with CMMC practices or processes.

2. Plan for and implement further procedures and practices to obtain the highest certification level possible. (Certification levels range from level 1 to level 5).

CMMC is divided into 5 levels. Each level has a set of questions that show maturity in the information and cybersecurity realm ranging from basic cyber hygiene practices (Level 1) up through standardized, optimized process across the organization (Level 5). Each level requires compliance with the lower-level requirements and institutionalization of additional processes to implement specific cybersecurity-based practices.

Level 1: A company must perform “basic cyber hygiene” practices, such as using antivirus software or ensuring employees change passwords regularly to protect Federal Contract Information (FCI).

Level 2: a company must document certain “intermediate cyber hygiene” practices to begin to protect any Controlled Unclassified Information (CUI) through implementation of some of the US Department of Commerce National Institute of Standards and Technology’s (NIST’s) Special Publication 800-171 Revision 2 (NIST 800-171 r2) security requirements.

Level 3: A company must have an institutionalized management plan to implement “good cyber hygiene” practices to safeguard CUI, including all the NIST 800-171 r2 security requirements as well as additional standards.

Level 4: A company must have implemented processes for reviewing and measuring the effectiveness of security practices and established additional enhanced practices to detect and respond to the changing tactics, techniques and procedures of advanced persistent threats (APTs)

Level 5: A company must have standardized and optimized processes in place across the organization and additional enhanced practices that provide more sophisticated capabilities to detect and respond to APTs.

The CMMC is expected to combine relevant portions of various cybersecurity standards, such as NIST SP 800-171, NIST SP 800-53, ISO 270001, and ISO 27032, into one unified standard for cybersecurity.

Unlike NIST SP 800-171, which measures a contractor’s compliance with a specified set of controls, the CMMC will more broadly “measure the maturity of a company’s institutionalization of cybersecurity practices and processes.”

The goal of CMMC is to provide a framework for the improvement of cybersecurity in the defense industry (described as the “defense industrial base”, or DIB). CMMC currently defines 17 domains of technical capability, each with five levels of certification (L1 through L5) and specific practices. This image from Carnegie Mellon University illustrates the 17 domains:

This image from the official CMMC framework documents explains the maturity levels ranging from ML1 to ML5:

SecureFLO will partner with your organization to build a security and privacy roadmap and a path to becoming CMMC compliant. We will work with your team to document business use cases and establish cyber hygiene controls so that the right people can access critical business data they need to perform their jobs.

SecureFLO will help your team understand the importance of compliance and can train your employees to participate in protecting personal data. Compliance is a journey, not a point in time. Business, technology, and standards change. SecureFLO can help you maintain continuous compliance with CMMC. SecureFLO services are available as subscription offerings so you can choose the right combination of services for your business and manage your budget efficiently.

The Defense Federal Acquisition Regulation Supplement (DFARS) is a set of restrictions on the sources of raw materials intended to protect the US defense industry from the vulnerabilities of being overly dependent on foreign sources of supply.

All U.S. Department of Defense (DoD) contractors that process, store or transmit Controlled Unclassified Information (CUI) must meet DFARS minimum security standards or risk losing their DoD contracts. DFARS provides a set of adequate security controls to safeguard information systems where the contractor or vendor data resides.

These standards were constructed to protect the confidentiality of Controlled Unclassified Information (CUI). When first enacted, DoD contractors were given until December 31, 2017 to meet the requirements necessary to be classified as DFARS compliant.

DFARS requires compliance by all contractors working within the federal supply chain, whether they are subcontractors working for a prime contractor, or contractors working for another company providing software-as-a-service (SaaS) or platform-as-a-service (PaaS) to the defense industry.

There are three ways contractors can comply with the DFARS (ranging from basic to intensive):

1. Contractors can self-assess their compliance, and make an attestation that they are complying with the DFARS and have implemented the NIST SP 800-171 security controls

2. A third-party organization can provide external audit of the contractor or certification that the contractor has met the requirements for certification

3. A federal team can be dispatched to inspect the contractor’s security plan

The Federal Acquisition Regulation (FAR) is the set of regulations governing all acquisitions and contracting procedures in the Federal government. DFARS addresses the defense industry. The U.S. Department of Defense (DoD) Chief Information Officer (CIO) is a reporting authority under the Defense Federal Acquisition Regulation Supplement (DFARS) clause 252.204-7012.

Any company that processes, stores, or transmits Controlled Unclassified Information absolutely must be to DFARS compliant. There are a few other instances that your business may also need to be DFARS compliant:

1. Are you a DoD contractor, subcontractor or involved with the DoD in a business arrangement? Then yes, very likely you will also need to complete a DFARS checklist.

2. Is DFARS provision 252.204-7008 contained within the language of a contract you are offering? Then absolutely, you do need to comply with DFARS.

3. Is DFARS provision 252.204-7012 contained within the language of a contract that you are offering? Then yes, you do need to comply with DFARS.

SecureFLO will partner with your organization to build a security and privacy roadmap and a path to becoming DFARS compliant. We will work with your team to document business use cases and establish cyber hygiene controls so that the right people can access critical business data they need to perform their jobs.

SecureFLO will help your team understand the importance of compliance and can train your employees to participate in protecting personal data. Compliance is a journey, not a point in time. Business, technology, and standards change. SecureFLO can help you maintain continuous compliance with DFARS. SecureFLO services are available as subscription offerings so you can choose the right combination of services for your business and manage your budget efficiently.

The Digital Operational Resilience Act (DORA) is a newly implemented EU regulation, effective from January 2023. This regulation is a crucial component of the EU Commission’s digital financial package, aimed at enhancing the digital resilience of the European financial market. The Digital Operational Resilience Act (Regulation (EU) 2022/2554) solves an important problem in the EU financial regulation. Before DORA, financial institutions managed the main categories of operational risk mainly with the allocation of capital, but they did not manage all components of operational resilience. After DORA, they must also follow rules for the protection, detection, containment, recovery, and repair capabilities against ICT-related incidents. DORA explicitly refers to ICT risk and sets rules on ICT risk management, incident reporting, operational resilience testing, and ICT third-party risk monitoring. This Regulation acknowledges that ICT incidents and a lack of operational resilience have the possibility to jeopardize the soundness of the entire financial system, even if there is “adequate” capital for the traditional risk categories.

DORA has two main objectives: to comprehensively address ICT risk management in the financial services sector and to harmonize the ICT risk management regulations that already exist in individual EU member states.

Information and Communication Technology (ICT) refers to a broad range of technologies that facilitate the management, storage, retrieval, transmission, and manipulation of information. It encompasses both hardware and software solutions, as well as various communication technologies. ICT plays a fundamental role in the modern world, impacting various aspects of society, business, education, and government. ICT is the infrastructure and components that enable modern computing.

Although there is no single, universal definition of ICT, the term is generally accepted to mean all devices, networking components, applications, and systems that combined allow people and organizations (i.e., businesses, nonprofit agencies, governments, and criminal enterprises) to interact in the digital world.

ICT encompasses both the internet-enabled sphere as well as the mobile one powered by wireless networks. It also includes antiquated technologies, such as landline telephones, radio, and television broadcasts — all of which are still widely used today alongside cutting-edge ICT pieces such as artificial intelligence and robotics.

ICT is sometimes used synonymously with IT (for information technology); however, ICT is generally used to represent a broader, more comprehensive list of all components related to computer and digital technologies than IT.

The list of ICT components is exhaustive, and it continues to grow. Some components, such as computers and telephones, have existed for decades. Others, such as smartphones, digital TVs, and robots, are more recent entries.

ICT commonly means more than its list of components, though. It also encompasses the application of all those various components. It’s here that the real potential, power, and danger of ICT can be found.

DORA was first proposed by the European Commission—the executive branch of the EU responsible for introducing legislation—in September 2020. It’s part of a larger digital financial package that also includes initiatives for regulating crypto-assets and enhancing the EU’s overall digital finance strategy. The Council of the European Union and the European Parliament (the legislative bodies responsible for approving EU laws) formally adopted the DORA in November 2022. Financial entities and third-party ICT service providers have until January 17, 2025, to comply with DORA before enforcement starts.

While the EU has officially adopted DORA, key details are still being ironed out by the European Supervisory Authorities (ESAs). The ESAs are the regulators that oversee the EU financial system, including The European Banking Authority (EBA), the European Securities and Markets Authority (ESMA), and the European Insurance and Occupational Pensions Authority (EIOPA).

The ESAs oversee drafting the regulatory technical standards (RTS) and implementing technical standards (ITS) that covered entities must implement. These standards are expected to be finalized in 2024. The European Commission is developing an oversight framework for critical ICT providers, which is also expected to be finalized in 2024.

As noted, DORA addresses the issue of ICT risk and incident management. The Regulation sets rules for ICT risk management, incident reporting, operational resilience testing, and ICT third-party risk monitoring, all of which we’ll briefly tackle in this article:

ICT risk management. DORA mandates financial entities, to achieve a high level of digital operational resilience, and put in place an internal governance and control framework to ensure the effective and prudent management of ICT risk. This framework will be overseen by the Management Body of the financial entity who must define, approve, and be responsible for the implementation of all arrangements related to the ICT risk management framework.

ICT incident reporting. The purpose of DORA is to mitigate ICT risk. But what if ICT incidents should happen anyway? Here, DORA lays out concrete incident reporting requirements. The gist of these requirements is to confirm entities have established appropriate procedures and processes to ensure consistent and integrated monitoring, handling, and follow-up of ICT-related incidents. Entities must also be able to ensure that root causes are identified, documented, and addressed to prevent the occurrence of such incidents.

Digital operational resilience testing requirements. Of course, ICT incident reporting processes must all be tested to ensure they will hold up during an ICT-related incident. Testing requirements intended to ensure digital operational resilience include the mandate to establish, maintain, and review a sound and comprehensive digital operational resilience testing program as an integral part of the ICT risk-management framework, for the purpose of assessing preparedness for handling ICT-related incidents, of identifying weaknesses, deficiencies, and gaps in digital operational resilience, and of promptly implementing corrective measures.

ICT third-party risk management requirements. The rationale behind DORA and analogous regulations is the growing risk associated with ICT third parties who offer critical services to financial services firms. As a result, the Regulation urges entities to manage ICT third-party risk as an integral component of ICT risk (more broadly) and within the entity’s ICT risk management framework. That framework, however, should be governed according to principles of proportionality. That means taking into account the nature, scale, complexity, and importance of ICT-related dependencies as well as the risks arising from contractual arrangements on the use of ICT services concluded with ICT third-party service providers.

When fully in force, DORA will cover a broad range of financial institutions, including the following:

• Credit institutions

• Payment institutions

• e-money institutions

• Investment firms

• Crypto-asset service providers

• Central securities depositories

• Managers of alternative investment funds

• UCITS management companies

• Administrators of critical benchmarks

• Crowdfunding service providers

• ICT third-party service providers

The Digital Operational Resilience Act (the “Regulation” is expected to constitute lex specialist to Directive (EU) 2016/1148 and the upcoming NIS 2. The Regulation’s proposal states that in relation to financial entities identified as operators of essential services pursuant to national rules transposing Article 5 of Directive (EU) 2016/1148, the Regulation shall be considered a sector-specific Union legal act for the purposes of Article 1(7) of that Directive which states that “Where a sector-specific Union legal act requires operators of essential services or digital service providers either to ensure the security of their network and information systems or to notify incidents, provided that such requirements are at least equivalent in effect to the obligations laid down in this Directive, those provisions of that sector-specific Union legal act shall apply”. Article 2 (6) of the NIS 2 proposal also states that “Were provisions of sector–specific acts of Union law require essential or important entities either to adopt cybersecurity risk management measures or to notify incidents or significant cyber threats, and where those requirements are at least equivalent in effect to the obligations laid down in this Directive, the relevant provisions of this Directive, including the provision on supervision and enforcement laid down in Chapter VI, shall not apply”.

DORA applies to all financial institutions in the EU. That includes traditional financial entities, like banks, investment firms, and credit institutions, and non-traditional entities, like crypto-asset service providers and crowdfunding platforms.

Notably, DORA also applies to some entities typically excluded from financial regulations. For example, third-party service providers that supply financial firms with ICT systems and services—like cloud service providers and data centers—must follow DORA requirements. DORA also covers firms that provide critical third-party information services, like crediting rating services and data analytics providers.

The General Data Protection Regulation (“GDPR”) is a law established by the European Parliament applying to personal data and was implemented in 2018.

GDPR enforcement is required to protect an individual’s sensitive personal data. Organizations that use and manage personal data should be GDPR compliant. As more personal data moves into the cloud, it is important for companies implement effective cybersecurity policies and procedures to be GDPR compliant.

GDPR was established for the personal data protection of the individual citizens of European Union (EU) countries and citizens of other countries whose data is collected in the EU while they are visiting an EU country for vacation or work. GDPR applies to research organizations who might have EU health data, genome data, or are sharing information for other purposes. GDPR also ensures the privacy of personal data that is exported outside of the EEA and EU zones.

GDPR aims to impose a unifying data protection law on all the member countries of the EU. As a result, no individual country in the EU will have to write their own data protection law. GDPR laws are therefore consistent across the EU.

Along with EU members, any organization or company using personal data of any citizen of the European Union for marketing or any other purposes is subject to the laws under GDPR.

Personal Data is identifiable information about any identifiable natural person. Under GDPR, Personal Data refers to any information such as name, identification number, location, address, cultural, economic, physical, financial, social, genetic, mental, and/or psychological data that can be used to identify an individual.

In some special cases, IP address, occupation, political views, hair color, and similar elements could be used to identify an individual. Also, biographical Information, appearance, behavior, workplace, education information, as well religion, political views, health & sickness information about an individual can be considered as Personal Data.

GDPR specifies rights that individuals have for the personal data under this regulation. There are several rights such as the right to be informed, right to access, right to rectify, right to erase, right to restrict processing, right to data portability, right to object and right not-to-be subject to automated decision-making includes profiling. Knowledge about these rights is essential for GDPR compliance.

GDPR requires that the individual provide updated consent for use of their personal data. And unlike the previous Directive 95/46/EC, GDPR requires protecting children’s data. If the child is less than 16 years old, then parental consent is required.

A data controller is a person, company, or other body that determines the purpose and means of personal data processing (this can be determined alone, or jointly with another person/company/body). For the official GDPR definition of “data controller”, see Chapter 4 of the GDPR regulations.

You are the data processor if you are instructed or tasked by a data controller to perform some of the following: Design, create, and implement IT processes and systems that would enable the data controller to gather personal data. For more information about data controllers and data processors, see Chapter 4 of the GDPR regulations.

In any organization, data controllers and data processors are required to be GDPR compliant. As a data controller, one must make sure to meet contractual obligations to be GDPR compliant. On the other side, as a data processor, maintaining records of processing activities and personal data use is needed to be GDPR compliant. For more information about data controllers and data processors, see Chapter 4 of the GDPR regulations.

In 1995, the Data Protection Directive 95/46/EC (“DPD”) was established to protect the personal data of the European citizens. The General Data Protection Regulation law was implemented in the first half of 2018.

The General Data Protection Regulation consists of 11 Chapters and 99 Articles in it. Also, it has 173 recitals remarks along with the 99 Articles. The Articles and the Chapters details can be found here.

Before you become a GDPR compliant, your organization must begin several important steps. First, the management team must support the organization’s goal of becoming GDPR compliant. Once the key players (management team) are aware of the regulations and GDPR laws, the organization must prepare documentation on the lifecycle of the data used in their business processes – how the data is accessed, stored, archived, cached. or managed within its data platform.

As the GDPR has replaced the Data Protection Directive (DPD), the organizations that were already following Directive 95/46/EC should clarify the differences with GDPR, and new rules to be followed for GDPR compliance.

Another requirement for GDPR compliance is to appoint a Data Protection Officer. For international businesses, appointing a Lead Authority is mandatory.

The data protection officer (DPO) is a mandatory role for all companies that collect or process EU citizens’ personal data, under Article 37 of GDPR. DPOs are responsible for educating the company and its employees about compliance, training staff involved in data processing, and conducting regular security audits.

GDPR non-compliance leads to real risks and potential penalties for any organization or individual that uses personal data or shares it. The most efficient way to be GDPR compliant is to follow these 5 steps:

1. Access the Data Source: The very first step to become GDPR compliant is to assess the personal data you or your company have collected for any purpose. The data source, irrespective of the technology (cloud or onsite storage), structured or unstructured data and so on, investigate personal data, the company has accessed, stored, archived, cached, managed or used for several purposes.

2. Identify and Categorize: Once the organization has access to the data source, they need to identify the personal data type. Most often, it has been seen that personal data is stored in semi-structured fields. In that case, you must identify and categorize the data into diverse sections accordingly such as name, social security number, email ID, and so on. Other than classifying and cataloging data, one must be aware of personal data quality. To be GDPR compliant it is necessary to have elements like standardizations, data quality rules, and data recognition.

3. Govern: In the governance model, it is mandatory to establish roles and access levels to access personal data. The organization must understand that personal data should be accessed only by authorized users who have the proper right and requirement to do so.

4. Protect: Data & Techniques: Once you finish establishing the roles and designations under the governance model, now it is time to protect and secure the data. There are three (3) techniques through which you can protect the data: encryption, pseudonymization, and anonymization.

5. Audit: The last step is to produce a detailed report about how you access, store, archive, manage and use personal data. In the audit report, your organization should document the following: type of data, the location, accessibility, the rights, & purpose for the user. The report also must state that you are aware of notification rules, and people who are involved in processing personal data have given their full consent for using their personal data.

A Lead Supervisory Authority is the authority with the primary responsibility for dealing with a cross-border data processing activity, for example when there is a data breach or when a data subject makes a complaint about the processing of personal data. A Lead Supervisory authority is not a separate person, it could be a DPO.

GDPR imposes significant fines which are intended to ensure best practices for data security and make it extremely expensive for companies to not adopt best practices.

The penalties depend upon whether the violations are considered less severe infringements or more serious infringements. Less severe infringements could result in a fine of up to €10 million, or 2% of the firm’s worldwide annual revenue from the preceding financial year, whichever amount is higher. More severe infringements could result in a fine of up to €20 million, or 4% of the firm’s worldwide annual revenue from the preceding financial year, whichever amount is higher. For more details about the General Data Protection Regulation non-compliance and penalties, click here.

You must report a breach to the Information Commissioners Office (ICO)with 72 hours of a breach.

SecureFLO will partner with your organization to build a security and privacy roadmap and a path to becoming GDPR compliant. We will work with your team to document business use cases and establish controls so that the right people can access critical business data they need to perform their jobs.

SecureFLO will help your team understand the importance of compliance and can train your employees to participate in protecting personal data. Compliance is a journey, not a point in time. Business, technology, and standards change. SecureFLO can help you maintain continuous compliance with GDPR. SecureFLO services are available as subscription offerings so you can choose the right combination of services for your business and manage your budget efficiently.

The Health Insurance Portability & Accountability Act (“HIPAA”) is a compliance regulation that mandates the protection of patient information for health institutions.

In 1996, then-President Bill Clinton signed the Health Insurance Portability and Accountability Act. This Act was passed to protect sensitive information about patients that is recorded and maintained by health care institutions and hospitals. The HIPAA Act was also passed to stop fraudulent activity and theft.

According to the Department of Health and Human Services, the health care system continues to move towards full computerization. Systems such as CPOE (Computerized Physician Order Entry), EHR (Electronic Health Records), Laboratory Information Management Systems (LIMS), Pharmacy, and Radiology are typically now all computerized and contain sensitive digital data. The benefit of electronic systems is that they make it easier and faster to access and manage data. On the other hand, digital data increases the security risk and the possibility of data theft or a cyber breach of the system. To prevent and protect from any unauthorized activity, healthcare organizations should be HIPAA Compliant.

Organizations that work with or have access to ePHI (electronic Protected Health Information) must be HIPAA compliant. This requirement ensures that sensitive data that the organization manages or accesses is protected from a breach or theft. Also, the companies working with ePHI should have the network and physical security measures to ensure and follow the rules for HIPAA Compliance.

If my firm is not a hospital, medical office, or health insurance provider, do we need to be HIPAA compliant? Any company that uses or works with ePHI must be HIPAA Compliant, including Medical Offices, Hospitals, and Health Insurance providers. Covered entities, business associates, subcontractors, or any other related associates must also be HIPAA compliant.

Covered Entities get direct consent from a patient to use her / her data. All health care organizations such as hospitals are covered entities since their health care professionals who provide treatment, handle payments, and manage operations have access to ePHI (electronic Protected Health Information).

Employers typically also get direct consent from their employees to use their health data, so they are often considered covered entities. Only employers who have self-insured health benefits like EAP (Employee Assistance Program) are called Covered Entities. Other organizations that have explicit or implicit consent to access ePHI (such as business associates) must be HIPAA compliant.

Business associates must be HIPAA compliant. Business Associates include anyone who has complete or partial access to patients’ electronic Personal Health Information (ePHI) and provides any support for treatment, operations, and payments. A business associate can be an individual or an organization. Examples of business associates are lawyers, accountants, Software-as-a-Service (SaaS) providers, Platform-as-a-Service (PaaS) providers, cloud storage services, billing companies, IT contractors, and email encryption service companies.

Before getting access to health data, business associates must sign a Business Associate Agreement (“BAA”). The BAA states the level of access to ePHI business associates may get, as well as whether the data should be returned or destroyed after using it.

To become a HIPAA Compliant, the organization or the covered entity or the individual needs to have these in place:

1. Administrative safeguards 2.Technical safeguards 3. Physical safeguards

All covered entities and business associates who access and manage ePHI must ensure that they have administrative, technical, and physical safeguards in place. These safeguards are mandatory for any company or covered entity to become HIPAA compliant. To protect the reliability of ePHI, companies must comply with the Privacy Rule in HIPAA.

According to the Department of Health and Human Services, the following are considered physical and technical safeguards an organization needs to have: Authorized access to ePHI along with limited facility access Constraints on accessing, using, transferring, destroying, re-using, removing of ePHI and electronic media. Ensuring policies on using and accessing ePHI Audit reports that records and tracks software and hardware system Use of unique IDs, auto log-off, emergency access process, encryption, and decryption.

Organizations and covered entities can check the HIPAA Checklist to ensure that they have fulfilled all the conditions to become HIPAA Compliant. These firms typically seek assistance from HIPAA experts to help them understand these requirements to become HIPAA Compliant.

There are five (5) Titles or Sections in the HIPAA 1996 Act.

Title 1 of the Act involves healthcare access, availability, renewal, and portability of the health plans. It also regulates the size of the group healthcare plans and individual healthcare insurance.

Title 2 of the Act establishes various policies and procedures that ensure the information protection. It also regulates policies that stop fraudulent activities. Title 2 provides all kinds of penalties against violation of the Act by the healthcare organization.

Title 3 ensures tax-related provisions in healthcare institutions. In 1997, the pre-tax medical savings account was made available for employees and self-employed medical professionals.

Title 4 identifies conditions for the group health plans and continuation of the coverage. It spells out the requirements for application and enforcement of the group health plan.

Title 5 specifies provisions for company-provided life insurance and premiums. It also ensures company endowment and tax-deductible loans.

The Security Rule, under Title 2 of the Act, ensures the protection of the patients’ health-related sensitive data.

The Security Rule requires that an organization’s policies must ensure that the data is confidential, has integrity, and is highly available. The rule also dictates that the controls that are put in place for the data lifecycle of ePHI must be documented. Ensuring that data is highly available may require deploying new technology.

Violation of HIPAA takes place when any of the Rules such as security rule or privacy rule are breached, or any of the addressable safeguards are not implemented. In that case, the organization or the covered entity must pay the penalty. The types of violations and resulting penalties are:

The HIPAA Breach Notification Rule requires that covered entities must immediately notify patients if their ePHI is breached or lost. They must also notify a US government agency.

Depending upon the size of the breach, a specific government agency must be notified:

If the number of patients whose information is breached is more than 500, then the covered entity must notify the Department of Health and Human Services.

If the number of patients whose ePHI is breached is less than 500, then covered entities will have to report to the Office of Civil Rights (OCR) Web Portal. These reports are to be made once a year as per the OCR requirements.

HIPAA Breach Reports must be submitted within 60 days of the breach detection.

Information that must be included in a Breach Notification are:

The nature of the breached ePHI The person or entity (unauthorized) who used or disclosed the ePHI Whether ePHI is viewed or acquired Extension of the risk of damage that has been alleviated.

HIPAA Omnibus Rule addresses topics that were not considered in earlier laws. The Omnibus Rule expands the areas of Privacy & Security Rule, compliance actions, Breach Notification Rules, and Penalties. The fine amount has been increased to $1 million for HIPAA breach of health records. The final Omnibus Rule was established in 2014. There are five key areas Omnibus Rule addresses:

1. Introduces final amendment under the HITECH Act (Health Information Technology for Economic and Clinical Health).

2.Introduces damage threshold and final rule inclusion in Breach Notification for UPHI (Unsecured Protected Health Information) under HITECH.

3.Prevention of the use of ePHI for marketing reasons.

4.Increased and tiered civil money penalty incorporation under the HITECH Act.

5.Inclusion of the provisions made by The GINA (Genetic Information Non-discrimination Act) and modification of HIPAA to stop the use of genetic information for underwriting purpose.

SecureFLO understands that protecting against cybersecurity risks and threats may require a culture change at your organization. We will be your advisory partner on this journey to gain HIPAA/HITECH compliance. Compliance with HIPAA begins with understanding and managing controls. Controls provide checks and balances to the data within the overall business operations. Controls are divided into two categories: Preventative and Detective. For example, if you have data that needs to be accessed by an external user, SecureFLO would create a control that defines his/her access (privilege), and we will monitor if they appropriately used that access by reviewing logs. SecureFLO services are available as subscription offerings so you can choose the right combination of services for your business and manage your budget efficiently.

The ISO 27001 standard provides requirements for an information security management system (ISMS). ISO 27001 enables organizations to manage the security of assets such as financial information, intellectual property, employee details, or information entrusted to third parties.

ISO 27001 was published by the International Standard Organization (ISO) and the International Electrotechnical Commission (IEC).

Organizations of any size can be ISO 27001 certified. Firms that access, collect, and manage customer and personal information should consider getting ISO 27001 certification.

The key benefits of getting ISO 27001 certified are gaining the trust of your clients and prospects. This may provide an advantage against your competitors who are not ISO 27001 certified.

Organizations that meet the ISO 27001 requirements may earn the ISO 27001 certification after completion of the audit by an accredited certification body.

The time it takes to get ISO 27001 certified depends upon the size and the complexity of the organization. With the right process and implementation, small and midsize businesses could complete the process in 6 – 12 months to get ISO 27001 certified.

Maintaining ISO 27001 certification requires at least one annual audit by your risk or cybersecurity team to ensure that your organization is meeting all the requirements of the standard.

The ISO 27001 Standard consists of 114 controls and 10 management system clauses.

Not every organization needs to implement all the 114 controls and 10 management system clauses. ISO 27001 considers a variety of attributes such as business type, size of the organization, volume of data flow, and business use cases while creating and running their information security management system (ISMS) in their organization. Organizations should perform activities that help them to implement appropriate controls under ISO 27001.

There are two mandatory activities and 10 clauses that must be completed to get ISO 27001 certification. The two mandatory activities are:

Clause 4.3: Scoping your ISMS where an organization needs to classify data to be protected. Clause 6.12: Conducting a risk assessment and defining a risk treatment methodology where an organization needs to identify and document threats to the data. The 10 additional requirements are: Clause 5.2 & 6.2: Information Security Policy & Objective Clause 6.1.3: Information Risk Remediation Process Clause 6.1.3e & 6.2: Risk Remediation Plan Clause 8.2: Risk Assessment Report Clause 7.2: Records of Training, Skill, Experience & Qualification Clause 9.1: Monitoring & measurement Results Clause 9.2: Internal Audit Program Clause 9.2: Results of Internal Audit Clause 9.3: Results of Management Review Clause 10.1: Results of Corrective Actions

Implementation of ISO 27001 requires the following:

Scope of the Project: Define the scope of the project and a security management system (SMS) objective. Decide whether to utilize an external auditor or hire in-house expertise (i.e. an internal auditor or security officer). Step 2: Identify the requirements: Identify the participants and the legal and regulatory requirements for implementation. Step 3: Risk Assessment: Conducting a risk assessment is a formal and compulsory step in ISO 27001 implementation as ISO does not specifically prescribe risk assessment. Plan the process and record the data, analysis, and results. The Statement of Applicability (SoA) and Risk Treatment Plan (RTP) must be produced after the risk assessment. Step 4: Review and Implement Controls: Once the risk is identified, the organization needs to decide whether the risk would be tolerated, treated, transferred, or terminated. Reviews should be properly documented as it must be produced to the auditor at the time of certification. Step 5: Internal Training: Organizations are required to conduct internal staff training to make employees aware of about cybersecurity policies and procedures. For example, every employee should protect their computers with a unique password before they leave their desk. Step 6: Develop appropriate documentation: Organizations must update and review documentation about policies and procedures. Step 7: Measure, Monitor, review & Internal Audit: This step involves continuous monitoring on improvement and process of ISO 27001 certification. While checking on the improvements, organizations must go through internal audits at planned intervals, at least annually. Step 8: Certified: Two stages of audits are conducted to get through the certification process: Stage 1: Assessment to understand whether the documentation meets the ISO 27001 requirements. If the organization does not comply with the standard, they need to make appropriate changes. Stage 2: A thorough assessment to establish whether the organization complies with ISO 27001/2.

It is important for organizations to choose a reputable Certification Body. Two issues to consider are: CASCO Standard – You should evaluate whether the certification body adheres to ISO’s Committee on Conformity Assessment (CASCO) standards. The CASCO Committee develops policy and publishes standards related to conformity assessment, but it does not perform conformity assessment activities itself. Accreditation – Check if the certification body you are considering is accredited. Accreditation is not mandatory, and non-accreditation does not necessarily mean it is not reputable. However, accreditation does provide independent confirmation of competence. To find an accredited certification body, contact the national accreditation body in your country or visit the International Accreditation Forum.

SecureFLO can advise your organization on how to become ISO 27001 certified. We partner with leading industry certification bodies for ISO 27001. SecureFLO can also train your team on IS0 27001 and help them participate in implementing your organization’s cybersecurity policies and procedures. SecureFLO services are available as subscription offerings so you can choose the right combination of services for your business and manage your budget efficiently.

A network security scan provides insight into the entire network and its nodes for security vulnerabilities and loopholes. A network security scan uses an automated solution that scans, assesses, and evaluates the security posture and strength of the underlying network.

A network scan is performed to manage, maintain, and secure the system using data found by the scanner. Network scans recognize available network services, discover and recognize any filtering systems in place, look at what operating systems are in use, and protect the network from cyberattacks.

Yes, there are three kinds of network scans:

1. Port Scanning – Detecting open ports and running services on the target host. 2. Network Scanning – Discovering IP addresses, operating systems, topology, etc. 3. Vulnerability Scanning – Scanning to gather information about known vulnerabilities in a target.

While every business need is different, it is a best practice to perform network vulnerability scans at least once per quarter.

Vulnerability scans are configured to review all network ports, detecting and identifying password breaches and suspicious applications and services. The scanning service reports security fixes or missing service packs, identifies malware and any coding flaws and monitors remote access.

The scan attempts to exploit each vulnerability that is discovered. Running a network vulnerability scan can pose its own risks as it is inherently intrusive on the target machine’s running code. As a result, the scan can cause issues such as errors and reboots, reducing productivity.

The length of time to do a risk assessment depends on both how many tests are performed and how responsive your organization is in providing information to the risk assessment service provider. Most projects for mid-size companies take between 1-4 weeks.

The NIST Cybersecurity Framework (“NIST CF”) was developed by the US National Institute of Standards and Technology (NIST) and provides cybersecurity guidance for public and private organizations operating in the United States.

The NIST CF is intended to help organizations manage and recover from cyber risks and threats as quickly as possible.

The NIST CF was designed for public and private businesses and organizations of all sizes.

According to a recent survey, approximately 70% of organizations and businesses view the NIST cybersecurity framework as the best approach to prevent, detect, and respond to cyber-attacks.

The first version 1.0 was released in 2014 by the NIST. The next and latest version 1.1 was released publicly on 16th April 2018. The new version includes guidance on supply chain risk management and interaction with supply chain stakeholders.

NIST is a standard rather than a regulation, so compliance is not mandatory for public or private organizations . There are no penalties or fees for non-compliance with NIST. NIST is considered a best-practice standard.

Recent studies concluded that large organizations could reduce security risk by 43% while smaller organizations successfully reduced it to 73% using the NIST CF.

Not implementing NIST could mean that your organization is susceptible to a cyberbreach. In 2017, the average cost of a data breach exceeds $3.6 million – which is much higher than the cost of implementing the NIST CF.

In addition to the monetary costs, other costs of a cyberbreach include loss of customers’ trust, damaged reputation, and lost revenue. Get more information about NIST CSF implementation and results here.

The cybersecurity framework is extremely flexible and can be customized for the organization’s needs.

The NIST Cybersecurity Framework is comprised of categories, sub-categories, and references to improve the critical infrastructure & cybersecurity of organizations.

NIST cybersecurity framework comprises of three main components.

1. The Core: The framework core depicts the functions to implement the cybersecurity framework using common and easy to understand language. The Core guides the organization to manage and reduce cyber risks and threats by augmenting existing cybersecurity processes. The framework core consists of five main functions: Identify, Protect, Detect, Respond, and Recover.

2. Implementation Tiers: The implementation guides organizations on how to assess cybersecurity and manage risk. It addresses budget and the company’s tolerance for risk.

3. Profiles: Framework Profiles help organizations prioritize and improve cybersecurity. Profiles align the organization’s objective, risk appetite, internal requirements, and resources with the outcomes of the framework core.

To learn more about the components of the NIST Cybersecurity Framework this link can be followed (here).

The NIST Cybersecurity Framework comprises of five core functions: Identify, Protect, Detect, Respond, and Recover. Each function is developed simultaneously with other functions to depict a security lifecycle in the system.

1. Identify: Develop the organizational understanding of cybersecurity risks to systems, assets, data, and capabilities.

2. Protect: Develop and implement the appropriate safeguards to ensure the delivery of critical infrastructure services.

3. Detect: Develop and implement appropriate activities to identify cyber security events.

4. Respond: Develop and implement the appropriate activities to respond to a detected security event.

5. Recover: Develop and implement the appropriate activities for resilience and to restore any capabilities or services that were impaired due to a security event.

Additional supporting material relating to the core functions of the NIST Cybersecurity Framework can be found here.

The five functions of the NIST CF Core (i.e. Identify, Protect, Detect, Respond, and Recover) are divided into 23 categories. Each category is divided into various sub-categories, with a total of 108 sub-categories. The details of the ‘Information Reference’ can be downloaded from here.

The five steps to implement the NIST CF are:

Step 1: Select Target Goals Before you begin with the implementation one must set a target goal. The organization should have agreement across departments about an acceptable level of the risk. It is important for an organization agree on the issues and prioritize which departments will be the focus before starting to implement the NIST CSF.

Step 2: Create a Detailed Profile Here, the organization is required to tailor the appropriate framework to their needs. There are 3 parts:

Risk management process Integrated risk management program External participation

Organizations may prefer to categorize differently and add them to the framework according to their organization’s requirement. Each of the categories runs from Tier 1 to Tier 4.

Tier 1 – Partial: Reactive and Inconsistent Framework.

Tier 2 – Risk Informed: Risk awareness and consistent planning.

Tier 3 – Repeatable: CSF standards and consistent policy.

Tier 4 – Adaptive: Proactive Threat Detection and prediction.

Tiers may also be customized by the organizations to align with their goals. Customized Tiers should be adopted by the key stakeholders to achieve organizational goals effectively and efficiently.

Step 3: Assessment of Current Position of Organization In this step, one needs to assess the security risk of the organization. It is wise to assess risk from not only within the functional department but also independently across the organization. Assessing risk can be done using trained staff members or the organization can hire a third-party to run the security risk assessment process. Also, it is required to identify the open-source and commercial software tools that will help organizations to achieve their goals. Phishing tests, vulnerability scanners, behavioral analytics, CIS benchmark testing and such are the examples of risk assessment. Threats and risks are required to be fully identified and documented. Before presenting it to the major stakeholders of the organization, the team implementing NIST CSF should aggregate and check the final score of achieving goals. The result understanding security risk to the organization, individuals, assets, and operations.

Step 4: Gap Analysis Action Plan Once a clear understanding of security risk to the organization is completed, one can move forward to the gap analysis. In this step, the team implementing CSF can compare the actual scores with the organization’s targeted score. The gap can be estimated through this process. Significant gaps between the two scores leads to identifying the damaged functional area and prioritizing them for better results. The next action would be to identify the appropriate activities to close the gap. Also, identifying project requirements, staffing levels, and budgetary consideration is part of this step.

Step 5: Action Plan implementation Finally, when you have all the threats assessed and documented, highlighted the gap analysis, and have potential actions to be taken to close the gap, your organization is fully ready to implement NIST CSF. It is a continuous process. Organizations keep assessing efficiency and reassessing the framework. The ongoing process of implementing CSF includes iteration and validation of the framework.

SecureFLO will provide a custom solution for your organization to attain compliance with the NIST Cybersecurity Framework. This may include assessment, documentation, process improvement, policy development and training your staff. SecureFLO will support your organization’s growth and development and keep you informed about emerging trends and technologies in the cybersecurity space. SecureFLO services are available as subscription offerings so you can choose the right combination of services for your business and manage your budget efficiently.

The New York Department of Financial Services (NYDFS) is responsible for the security of financial service organizations operating in New York state.

In February 2017, the New York Department of Financial Services (NYDFS) established the NYDFS Cybersecurity Regulation, namely 23 NYCRR 500. This regulation includes rules and guidelines that financial service firms must follow. All covered & affiliated entities are required to comply with 23 NYCRR 500 requirements to protect the sensitive data they collect and manage.

New York is a global hub for financial services, all of whom are at risk for cyber-attacks and data breaches. According to Forbes, financial services firms are victims of cyber-attacks and thefts 300 times more frequently than other industry verticals around the world. The Forbes article states that an average of 30 attacks are reported every second.

Any organization or financial service firm based in or with a branch located in New York must comply with 23 NYCRR 500. The regulation also applies to third-party suppliers of NY based organizations. In addition, organizations that do not have headquarters in NY but operate or have a permit, license or any other authorization under New York banking regulations or laws must comply with NYDFS Cybersecurity Regulation.

More than 3,000 financial service firms are covered under NYDFS regulation 23 NYCRR 500.

The following organizations must comply with 23 NYCRR 500:

1. State Chartered Banks

2. Private Banks

3. Any foreign banks that operate in New York

4. Insurance Companies

5. Mortgage Companies

6. Licensed Lenders

7. Service providers for covered institutions

Some of the organizations that are exempt from 23 NYCRR 500 include:

1. Any organization that has less than 10 employees

2. Any organization that has reported annual revenue of less than $5 million

3. Any organization that has assets less than $10 million

4. Any charitable organization

5. Any foreign exchange risk organization that operates in New York state

6. Any licensed organization that does not control, store, and access or receive public data beyond any information related to corporate affiliation.

Businesses within the banking, insurance and other financial services industry within New York City or if you provide a service or on contract as a vendor to these industry firms, you will need to follow and be subject to these rules as well. You will also need to be compliant with the regulations and rules and have the right systems in place for security and data storage encryption of information. Regulation 23 NYCRR 500 also requires organizations who process or hold personally identifiable information to implement adequate security measures to protect against personal data loss.

There are 23 regulatory standards under the NYDFS Cybersecurity Regulation. The regulations and the definitions are available in detail here.

The 23 NYCRR 500 works by imposing minimum standards on covered entities. The standards describe a set of steps that begin with deploying a cyber-security protection plan and appointing a Chief Information Security Officer (CISO).

The Chief Information Security Officer (CISO) supervises the implementation of the 23 NYCRR 500 Regulations. The CISO is also responsible for the maintenance and ongoing reporting system under 23 NYCRR 500. Additional information about CISO roles and functions are available here.

The NYDFS Cybersecurity Regulations include five core functions set by forth under the NIST Cyber-Security Framework (CSF). These five core functions are as follows:

1. Identification: Identification of the organizational understanding of cyber risk to the system, data, assets, and capabilities of the organization.

2. Protection: Employment of defensive infrastructure to protect the system from threats

3. Detection: Implementation of the appropriate activities to identify the threats

4. Response: Take appropriate steps to alleviate detected threats

5. Recover: Restoration of any service or capability that is damaged by the threats

The four phases of the regulation are designing the cyber-security policy, cyber-security reporting procedures, program development, and third-party security.

The NYDFS regulation does not spell out any penalties clearly for non-compliant organizations. Though the regulation does not specifically address penalties, it falls under the NY Banking Law. The regulation clearly states that ‘for any violation of regulations promulgated’, penalties are applied based on NY Banking Law. Accordingly, there are three tiers of penalties:

1. $2,500 will be charged per day during the time of a violation.

2. $15,000 will be charged per day during the practice of discounting.

3. $75,000 will be charged per day for violations done willfully and knowingly.

Your organization should Implement appropriate safeguards, technical standards, and policies, such as, data encryption of personal data / personal identifiable information (PII) to mitigate risk of non-compliance. Other activities include:

1. Map products & devices – Map internal and external products / devices that store data

2. Logging – Log and require company equipment used to be covered under your data security policy and ensure data encryption is utilized. Items such as, but not limited to servers, hard drives, SSDs, USB Flash drives, computers, and mobile devices.

3. Inventory Analysis – Evaluate the amount of personal data in totality.

4. Purge – Eliminate archives of unnecessary personal identifiable information (PII).

5. Controllers of Information – Review privacy risk and impact assessments.

6. Contracts – Future-proof your business by enacting mandatory policies now

Regulation 23 NYCRR 500.17(a) requires Covered Entities to notify the superintendent of certain Cybersecurity Events as promptly as possible but in no event later than 72 hours from a determination that a reportable Cybersecurity Event has occurred.

Not all risks or violations are required to be reported within 72 hours under the regulation. For example, if there is a malware attack on a website with marketing information with no access to sensitive data there is no reporting requirement. The reporting requirement would be for a critical system that wires money to international banks with intermediary information.

Once a year, the CISO must submit the documentation about assessments and policies to the governing body of the NYDFS. However, other documentation requirements are more onerous. The CISO must provide reports and documents if any critical incident that caused a threat or vulnerability has been reported.

All covered organizations must monitor risks and threats. An assessment should be conducted periodically. Since the CISO must submit reports of compliance annually, an assessment should be done at least once a year.

SecureFLO will partner with your organization to build a security and privacy roadmap and a path to becoming GDPR compliant with 23 NYCRR 500. SecureFLO can help your team understand the importance of compliance and can train your employees to participate in protecting sensitive data. SecureFLO services are available as subscription offerings so you can choose the right combination of services for your business and manage your budget efficiently.

The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard created for companies to protect against credit card fraud, develop practices to strengthen network security, and protect sensitive data. PCI DSS is administered by the Payment Cards Industry Security Standards Council (PCI SSC)

The Payment Cards Industry Security Standards Council (PCI SSC) is a global organization that brings together payments industry stakeholders (including credit card companies) to develop and drive adoption of data security standards and resources for safe payments worldwide. The council was established to manage and control the development of the PCI DSS standard.

When was the Payment Cards Industry Security Standards Council established? The Payment Cards Industry Security Standards Council (PCI SSC) was founded in 2006 by American Express, JCB International, Visa, Discover Financial Services and Master Card.

What types of organizations must be PCI DSS compliant? According to the Payment Cards Industry Security Standards Council (PCI SSC), any firm that processes, stores, controls, and transmits credit card data of any cardholder must be PCI compliant. Any merchants who are involved in data processing for card payments are required to be PCI compliant. For example, e-commerce businesses are required to be PCI compliant. Being PCI compliant ensures that sensitive data shared by cardholders with companies for internet transactions are safe and secure.

Why was the PCI DSS standard implemented? The main goal of PCI DSS is to reduce the rampant credit card fraud worldwide. The PCI DSS standard provides protection and security for the payment details of the credit and debit cardholders to protect their sensitive data.

How many credit cards have been stolen? According to a study published by Forbes, in November 2018, nearly 75.9 million stolen credit cards were on sale on Dark Web during the prior 12 months. 60 million cards among the total numbers are found to be from US owners, reported by threat intelligence firm Gemini Advisory. The large number of stolen credit cards illustrates why merchants, agencies, e-commerce businesses and/or any company that is involved in internet payment processing must be PCI DSS compliant.

How often must compliance with PCI DSS be validated? PCI DSS compliance is a continuous process. Organizations must validate that they are PCI DSS compliant either quarterly or annually.

Who validates that an organization is compliant with PCI DSS? There are three roles that can perform the validation of compliance with PCI DSS:

1. Qualified Security Assessor (QSA) or QSA companies – for firms that handle a large volume of internet transactions or card payments, an external QSA typically performs the PCI compliance assessment.

2. Internal Security Assessor (ISA) – some larger firms may have an ISA on staff to validate compliance with PCI DSS.

3. Self-Assessment Questionnaire (SAQ) – firms with a small volume of transactions may choose to use the SAQ to validate compliance with PCI DSS.

How have security standards for the payment card industry evolved? Various security standards for the payment card industry have been in place since the 1990s. Secure Socket Layer (SSL) is a security standard that securely connects a user’s web browser user to the web server that is processing their payment. The first version of SSL was released in the early 1990s, and the second version was released in 1995.

In 1999, Transport Layer Security (TLS) was established. TLS replaced SSL with the release of TLS version 1.0. Since then, PCI payment standards are updated frequently to protect users’ data during internet payment processing.

Merchants are required to be PCI DSS compliant so that the connection and data transfer between the user’s web browser and the webserver is done securely.

What was the role of credit card companies in establishing the PCI DSS standard? During the 1990s and 2000s, given extensive credit and debit card fraud, American Express, Visa and Master Card developed approaches to address fraud. In 2001, Visa introduced the “Cardholder Information Security Program”. Other card companies introduced their own company standards. Merchants and point of sale (POS) terminals were required to comply with those standards.

In 2004, American Express, MasterCard, and Visa established a single standard, the Payment Card Industry Data Security Standard (PCI DSS).

In 2006, American Express, JCB International, Visa, Discover Financial Services and Master Card established the PCI Security Standards Council. The council was established to manage and control the development of the PCI DSS standard.

Have there been recent updates to the PCI DSS standard? The first version of the PCI DSS was released in 2004. The current version is 3.2.1 that was released in 2018.

What are other risks besides fines for not being PCI DSS compliant? Apart from the costs of the penalties, non-compliance with PCI DSS can result in other costs to the business. Those additional costs include fees from banks (for violating merchants), lost revenue, federal audits, and lawsuits. For details refer to the following link here.

As per the PCI DSS guidelines, there are 4 levels of non-compliance merchants, based upon the total number of annual transactions. The fines and charges under each level of non-compliance companies are as follows:

Level 4 merchants are required to be PCI compliant, but they are not subject to any fines for non-compliance given they are small companies. [Data source: http://pcidsscompliance.net/overview/fines-for-non-compliance/]

To comply with PCI DSS, there are 12 requirements that cover all elements of the Cardholder Data Environment (CDE) which includes users, processes, workflows, and systems / networks that save, process, and transmit authentication data. The following are the 12 requirements for PCI compliance:

1. Install and maintain a firewall configuration to protect cardholders’ data 2. Change vendor-supplied defaults for system passwords and other security parameters 3. Protect stored cardholders’ data 4. Encrypt transmission of cardholders’ data over the open, public, network 5. Protect all the systems against malware and regularly update anti-virus software programs 6. Develop and maintain a secure system and application 7. Restrict cardholders’ data to only authorized personnel 8. Identify and authenticate access to system components 9. Restrict physical access to the data of the cardholder 10. Track and monitor all access to network resources cardholder data 11. Test regularly security systems and processes 12. Maintain security policy for all personnel. The detailed requirement and sub-requirements are available here.

All these mentioned requirements are categorized into three parts,

a. Requirement description b. Testing procedure c. Guidance

There are three broad steps to attain PCI DSS compliance:

1. Data Scoping: Data scoping is done annually before the assessment. This process involves identifying the systems and their components that are connected with or located within the CDE. For PCI DSS compliance, the merchants must confirm that all systems and components connected to the cardholders’ data are identified.

2. Assessment: Assessment is done by Qualified Security Assessors. Data security firms that are qualified by the PCI SSC can perform the assessment for the merchants. Some of the tasks that assessors perform are verification of the technical information, confirmation of meeting the standard, providing support and guidance for compliance, and final reporting. The detailed steps of the assessors’ performance are listed here.

3. Reporting: Final reporting is the final step for the merchants to be PCI DSS compliant. These reports are made by the Assessors. Merchants report their compliance status to the respective card brands they are working with.

Any business that stores, processes, and transmits cardholder data should understand the risks of not being compliant with PCI DSS and develop a plan to manage risk. Critical steps to manage risk are:

1. Identifying risk – Risk identification is the first step. Even after using specialized risk management tools such as a hardware security module (HSM), the business may still face risks and vulnerabilities.

2. Risk Analysis – After identifying the risk, businesses must analyze the nature of the risk. In the case of a cryptography module or HSM, the risk may be from using older versions of encryption technology or not patching hardware with necessary software updates. If the configuration is complex, the risk involved is much greater.

3. Risk Remediation: If there are technological risks, a combination of talented security experts, well-defined processes, and technology can remediate the risk. Because a data breach could occur anytime for agencies or merchants, PCI DSS compliance is a continuous process. Proper certification or guidelines make remediation easier.

4. Risk monitoring – A data breach can happen to the smallest organization or the largest enterprise, including government entities. To reduce risk, it is highly recommended to continuously monitor your system, applications, operating systems, network, and address any vulnerabilities in a timely manner.

Compliance with PCI DSS is a continuous process that must be performed at least annually. SecureFLO can help your organization become PCI DSS compliant and maintain compliance.

We will work with your team to map your business use cases and data lifecycle. We can perform penetration testing, vulnerability scanning, secure code reviews, and train your employees.

SecureFLO partners with Qualified Security Assessors (QSAs) who are authorized to validate compliance with the PCI DSS standard.

SecureFLO services are available as subscription offerings so you can choose the right combination of services for your business and manage your budget efficiently.

A penetration test often called a “pen test” or “ethical hacking,” is an authorized simulated cyberattack on a computer system performed to evaluate the system’s security. A pen test is different from a vulnerability assessment.

A pen test is designed to simulate different attack vectors, from either inside or outside the environment. Penetration tests may include networks, applications, devices, behavioral tests, and physical tests.

Some examples of pen tests include: 1. Internal/External Infrastructure Penetration Testing 2. Wireless Penetration Testing 3. Web Application Pen Test 4. Mobile Application Pen Test 5. Build and Configuration Review Pen Test 6. Social Engineering Pen Test 7. Physical Pen Test on a Location

No, all industries with internal or external users accessing applications or services over the internet or intranet should conduct a penetration test. Companies with sensitive personally identifiable data (PII, IP, PHI) within their network are at risk of cyberattack and should conduct pen tests on critical components of their IT infrastructure.

We recommend performing penetration testing regularly – at least once a year- ideally quarterly or monthly. Ongoing pen tests ensure consistent IT and network security management by identifying how malicious hackers might exploit newly discovered threats (0-days, 1-days) or emerging vulnerabilities.

Penetration tests include five phases. An ethical hacker will follow the same steps on a target environment that a potential hacker might perform but instead seek to find opportunities to strengthen its security:

1. Planning and Reconnaissance by gathering important information on the target system to find areas that hackers might try to exploit with a cyberattack. For example, an attacker might attempt to use open-source search engines to find data to use in a social engineering attack.

2. Scanning using technical tools to enhance their understanding of the target system. For example, NMap can be used to scan for open ports.

3. Gaining System Access using a payload to exploit the target system using the data gathered in the reconnaissance and scanning phases. For example, Metasploit can be used to automate attacks on known vulnerabilities.

4. Maintaining Persistent Access by taking steps to maximize the time spent accessing the target environment to gather as much data as possible.

5. Covering tracks by clearing any trace of compromising the target system, any type of data gathered, or log events.

After completing the penetration test, the ethical hacker will summarize their findings in a report for the client.

There are some potential risks of conducting a penetration test at your organization:

1. System Outages. Penetration testers are hired to break through security controls and exploit vulnerabilities. 2. Inadvertent exposure 3. Masking of Attacks 4. Lost Productivity 5. False Negatives 6. Unethical Hackers

An ethical hacker will work with the client organization to minimize these risks.

A penetration test engagement should take between one to three weeks to perform. The time to write a summary report may vary based on the company conducting the pen tests and their specific processes.

Phishing is a type of social engineering that begins with an attacker sending a fraudulent message. The message is designed to trick the recipient into revealing sensitive information to the attacker or enable the hacker to deploy malicious software on the victim’s infrastructure (such as ransomware).

Phishing Emails comprise a large portion of the world’s yearly slate of devastating data breaches. The attacker sends a fraudulent message to trick the recipient into revealing sensitive information or enable the hacker to deploy malicious software via the victim’s device.

Spear Phishing targets specific individuals instead of a broad group of people. According to the SAN Institute, 95% of all attacks on an enterprise network result from a successful spear phishing.

Whaling /CEO fraud is a form of spear phishing that directed at senior executives. Once whaling is successful, attackers can engage in CEO-level fraud. After an executive’s email is compromised, the attacker can use the victim’s email to authorize fraudulent wire transactions to transfer funds to a financial institution that the hacker can access.

Vhishing is a form of social engineering designed to obtain sensitive information through phone calls.

Evil Twin is a fake Wi-Fi access point set up to lure unsuspecting users to a phishing site when they connect to it. The attacker eavesdrops on the user’s communication and log-in credentials, which are later used to gain access to the network.

Link Manipulation is a form of phishing whereby attackers intentionally misspell URLs and subdomains to mislead users and harvest sensitive information.

Pharming is where attackers redirect users trying to reach a genuine website to a fake site. These counterfeit sites aim to steal users’ sensitive information.

Content Injection is when attackers exploit a web vulnerability and inject their content on a website to mislead users to a malicious website.

Session Hijacking relies on websites accepting session IDs from URLs resulting from phishing attempts. An attacker can email a link to a user that contains a session ID.

Malware is corrupt and malicious software that gets surreptitiously installed and run on a system and targets the victim’s infrastructure. Ransomware is one example of malware.

POPIA (Protection of Personal Information Act) (often called the POPI Act or POPIA) is a South African law that ensures that any personal information that you give out is protected. The law stipulates a set of rules that organizations must follow in terms of how they collect, use, keep, or remove data.

The law has been effective since 1 July 2020

POPI applies conditions for the lawful processing of personal data of South African citizens and those living in South Africa.

Any person or organization who keeps records relating to personal information, such as an individual’s name, signature, address, phone number, credit information, or date of birth, unless those records are protected by other legislation more stringently, needs to comply with the Popi Act. It sets the minimum standards for the protection of personal information.

The purpose of the POPI Act to is protect personal information, striking a balance between the right to privacy and the need for the free flow of information as well as the access to information, whilst regulating how personal information is processed. It is intended to protect consumers and legitimate businesses from those that don’t comply.

Ensure your employees are aware of the POPI Act and adhere to the regulations set out.

Assess how your clients and employees’ data is collected, stored, processed, and eventually disposed of.

Review, create, and set up the correct policies and procedures to ensure the compliant processing of personal information.

Policies and procedures should be assessed or audited by a POPI specialist to make sure they align with the requirements of the POPI Act.

Adequate communication and training should be implemented for your staff with regard to all policies and procedures.

The South African Information Regulator may institute a fine or imprisonment of up to 12 months. (Section 107 of the POPI Act)

In some cases, depending on the Sections of the Act you do not comply with, or if convicted of an offense in terms of the Act, you may be liable for a fine of up to 10 million or up to 10 years imprisonment. If your clients are impacted by a data breach, POPIA even empowers them to take civil action for damages.

POPI is the act of protecting Personal Information, implying that all the policies, procedures, processes, and practices in the organization relating to personal information, are in fact doing POPI. POPIA is merely the name of the law, and so you cannot “do” POPIA. To comply with POPIA, you need to implement a POPI program.

POPI does not apply to a deceased person because the definition of ‘personal information’ requires that the data subject (i.e., the person) be ‘living’.

No, the POPI Act does not apply to social media as it does not protect public information. Any information that you share publicly will automatically fall outside of this Act’s protection. If you list your email address or mobile number on any social media platform, and that information is publicly available, it is then free for companies to collect and use.

The role players are :

The data subject: the person to whom the information relates.

The responsible party: the person who determines why and how to process, such as profit companies, non-profit companies, governments, state agencies, and people. Responsible for the lawful processing of personal information.

The operator: a person who processes personal information on behalf of the responsible party such as an IT specialist or lawyer.

The Information Officer of an organization is the “go-to” person when it comes to information. By default, every South African organization has one. Did you know that the Promotion of Access to Information Act or PAIA automatically designates a person in each organization as an officer? This person is different from the Chief Information Officer or CIO. That person is specifically called an Information Officer.

The role of the information officer is to encourage compliance by the company with the conditions for the lawful processing of personal information in terms of POPIA

• Deal with requests made to the organization in terms of POPIA;

• Work with the Information Regulator in relation to investigations conducted in relation to the body; and

• Otherwise, ensure compliance by the body with the provisions of POPIA

• Make sure a compliance framework is developed, implemented, monitored, and maintained

• Develop, monitor, maintain, and make available a PAIA manual,

• Ensure that a personal information impact assessment is done in the company so that adequate measures and standards exist to comply with the conditions for the lawful processing of personal information.

• Subject to the exemptions already mentioned, a manual is developed, monitored, maintained, and made available as prescribed in terms of POPIA and PAIA

• Develop measures and adequate systems within the organization to process requests for access to information.

• Ensure that internal awareness sessions are carried out regarding the provisions of POPIA.

A secure code review is a manual or automated process that examines an application’s source code. The goal of this examination is to identify any existing security flaws or vulnerabilities.

A secure code review is performed using manual or automated processes (or both) to examine an application’s source code.

Reviewing your source code provides a fresh set of eyes to spot bugs and simple coding errors before your code base moves to the next step in your release process. Reviewing your code enables you to manage vulnerabilities before releasing your application into production and improves your customer’s experience (and security) using your software.

The primary benefit of performing a code review early in the development process is the time saved in the long run compared to fixing bugs identified after releasing the software to your customers. Locating and fixing flaws and vulnerabilities after a hacker successfully executes a cyberattack could cost you and your customers a lot of money and damage your and their reputation. Code reviews standardize security across your code base, improving your release management process.

A manual code review involves thoroughly reviewing the entire codebase by a senior or more experienced developer. This process can be extremely tedious and time-consuming, but it identifies flaws, such as business logic problems that automated tools may miss.

An automated code review enables large codebases to be quickly and efficiently analyzed. The review is performed using either open source or commercial tools to help find vulnerabilities in real-time.

Some best practices we recommend when performing a secure code review are:

1. Create a comprehensive Secure Code Review Checklist 2. Review continually 3. Use Threat Modeling 4. Utilize automation tools to save time (but don’t rely on automation to do everything for you) 5. Draw upon the expertise of an Application Security Professional 6. Validate your input and output 7. Enforce Least Privilege.

Service Organization Controls 2 (“SOC 2”) is an audit reporting standard established by the American Institution of Certified Public Accounts (AICPA).

SOC 2 reports are issued by AICPA auditors who review a company’s financial books.

SOC 2 Certification is largely used by Software-as-a-Service (SaaS) organizations, Platform-as-a-Service (PaaS), and data companies to explain how they manage and protect clients’ data that is saved in the cloud or in an enterprise environment.

Any organization that handles, manages, and saves customers’ sensitive data such as personally identifiable information (PII), electronic protected health information (ePHI), payment information, or intellectual property (IP) should consider becoming SOC 2 Compliant. SOC 2 includes strict policies and principles for managing and protecting data.

SOC 2 is often required by internal auditors, IT managers, risk managers, and other operators and regulators supporting business units. Sales may also request SOC 2 compliance.

During the sales process, the salesperson may be asked by a prospect to describe the security and privacy policies for the SaaS or PaaS solution they are selling. A SOC 2 Compliance Report provided by the salesperson to the prospect often addresses the prospects’ concerns about security and privacy.

Becoming SOC 2 Compliant is voluntary, not mandatory. Companies often get SOC 2 certification because certain clients requested it or require it.

Prospective customers of SaaS & PaaS organizations and data companies may request SOC 2 compliance and certification if those firms will access sensitive data (PII, ePHI, social security numbers, credit card numbers, intellectual property, etc.)

Some of the benefits of an organization becoming SOC 2 compliant are:

1. Getting SOC 2 certified ensures that the company has utilized skilled cybersecurity resources and implemented policies and technology to handle sensitive data according to the SOC 2 standard.

2. SOC 2 Certification allows a company to demonstrate that they have implemented security controls. A SOC 2 certification report can be shared with multiple prospects and/or clients.

3. SOC 2 Compliance conveys to customer prospects and to Cloud, IT, and Hosting Providers that the organization’s policies and procedures can be trusted.

SOC 2 Certification assures your clients and prospects that their sensitive data is accessed, stored, managed, and disposed of in a secure manner. Not only is the data protected from malware, internet threats, and cyber events, but SOC 2 certification demonstrates that you have implemented have secure operational practices in the cloud, during development, and the endpoints.

SOC 2 compliant procedures and policies must exhibit the following five basic principles:

1. Security 2. Availability 3. Processing Integrity 4. Confidentiality 5. Privacy

The SOC 2 system requires controls, testing, security policies, documented evidence of functioning, architectural diagrams, well-written procedures, and annual updates.

Yes, there are four different types of SOC compliance:

SOC 1: If you need to report to regulators about Financial Controls, then you must have SOC 1 compliance.

SOC 2: SOC 2 reports focus on controls like privacy, security and managing clients’ data stored in the cloud. SOC 2 is used by the internal auditors, IT managers, risk managers, operators, and regulators along with lines of business.

SOC 2+: If you need more or extension to the trust and principles accepted by the service companies, or if you need to address other regulatory support and compliance like GDPR, HITRUST, and NIST, then SOC 2+ is the best suitable compliance for your company.

SOC 3: SOC 3 is more of a simple report that focuses on the marketing support of any company. If you need to have a simple report that supports, your marketing principles then SOC 3 will be the best option.

SOC 1 reports are focused primarily on public companies (whose shares are traded on stock exchanges). SOC 2 is slightly different from SOC 1. SOC 2 reports focus more on the information technology, although the approach for both the reports is the same.

A SOC 1 Type 1 report demonstrates that your company’s internal financial controls are properly designed. A SOC 1 Type 2 report further demonstrates that your controls operate effectively over a period of time.

The process of getting a SOC 2 certificate takes at least 6 months.

Two phases must be completed meet the requirement of the SOC 2:

Phase 1 – Focuses on readiness where you establish and document controls, conduct an assessment, document evidence, collect process documents and prepare for the Audit.

Phase 2 – Retain an AICPA internal Audit firm to certify the controls and write a report which confirms your SOC 2 Certification.

A SOC 2 Type 1 Audit involves assessment at a point of time, while a SOC 2 Type 2 Audit involves assessment over a period of time. Completing the first phase of SOC 2 results in getting a SOC 2 Type 1 certificate. After 6 months, the steps to get SOC 2 Type 2 certification can begin.

Once the team is formed, they will conduct a readiness assessment and define the audit scope. Next, the team will write well-defined information security policies and procedures. After that, they can proceed with the implementation of plans to bridge any gaps identified. Finally, the team will engage a third-party assessor who will complete the SOC 2 Type 1 Audit.

The SOC 2 Type 1 Report is issued by a Third-Party Auditor. Once this report is issued, the Type 2 certification process can begin. A SOC 2 Type 1 Audit Report can guide the organization to resolve identified gaps during the 6-month time period.

The SOC 2 Type 2 auditor will verify the effectiveness of the controls over a period.

SOC 2 Certification must be updated annually.

SecureFLO will help you manage and protect your sensitive data and achieve SOC 2 Certification. We will coordinate with your organization and an independent AICPA audit firm and help navigate the process for SOC 2 certification.

SecureFLO services are available as subscription offerings so you can choose the right combination of services for your business and manage your budget efficiently.

FDA medical device security refers to the measures and protocols implemented to safeguard the cybersecurity of medical devices regulated by the U.S. Food and Drug Administration (FDA). It aims to protect these devices from potential threats and vulnerabilities that could compromise their functionality and patient safety.

Ensuring the security of medical devices is crucial to prevent unauthorized access, data breaches, and other cyber threats that could impact patient health. It also helps maintain the integrity and reliability of medical devices in delivering accurate and safe healthcare services.

The FDA primarily focuses on the cybersecurity of medical devices that are connected to networks, the internet, or other devices. This includes devices like insulin pumps, pacemakers, infusion pumps, and other connected healthcare technologies.

Common cybersecurity risks include unauthorized access to patient data, malware attacks, denial-of service attacks, and potential manipulation of device functionality. These risks can pose serious threats to patient safety and data security.

The FDA provides guidance and regulations for manufacturers to follow during the development and post market management of medical devices. This includes recommendations for risk assessments, threat modeling, and the implementation of security controls to mitigate potential risks.

Manufacturers can follow best practices outlined by the FDA, such as incorporating security measures during the design phase, regularly updating and patching devices, and conducting thorough testing to identify and address vulnerabilities.

Yes, the FDA has released guidelines and recommendations for medical device cybersecurity. Manufacturers are encouraged to follow these guidelines to meet regulatory requirements and enhance the security of their products. The guidlines provided are divided into three sub sections:

• Postmarket management of cybersecurity in medical devices

• Quality system considerations and content of premarket submissions

• Cyber security for networked medical device containing off-the-shell (OTS) software

This guidance clarifies FDA’s postmarket recommendations and emphasizes that manufacturers should monitor, identify, and address cybersecurity vulnerabilities and exploits as part of their postmarket management of medical devices. This guidance establishes a risk-based framework for assessing when changes to medical devices for cybersecurity vulnerabilities require reporting to the Agency and outlines circumstances in which FDA does not intend to enforce reporting requirements under 21 CFR part 806. 21 CFR part 806 requires device manufacturers or importers to report promptly to FDA certain actions concerning device corrections and removals. However, the majority of actions taken by manufacturers to address cybersecurity vulnerabilities and exploits, referred to as “cybersecurity routine updates and patches,” are generally considered to be a type of device enhancement for which the FDA does not require advance notification or reporting under 21 CFR part 806.

For a small subset of actions taken by manufacturers to correct device cybersecurity vulnerabilities and exploits that may pose a risk to health, the FDA would require medical device manufacturers to notify the Agency. Risks to health posed by the device may result in patient harm. This guidance recommends how to assess whether the risk of patient harm is sufficiently controlled or uncontrolled. This assessment is based on an evaluation of the likelihood of exploit, the impact of exploitation on the device’s safety and essential performance, and the severity of patient harm if exploited.

This guidance applies to any marketed and distributed medical device including:

1) medical devices that contain software (including firmware) or programmable logic; and

2) software that is a medical device, including mobile medical applications. In addition, this guidance applies to medical devices that are considered part of an interoperable 10 system and to “legacy devices, i.e., devices that are already on the market or in use.

The guidance is not limited to devices that are network-enabled or contain other connected capabilities. Software validation and risk management are key elements of cybersecurity analyses and demonstrating whether a device has a reasonable assurance of safety and effectiveness. FDA requires manufacturers to implement development processes that account for and address software risks throughout the design and development process as part of design controls, as discussed in FDA’s regulations regarding design control, which may include cybersecurity considerations

may beone way to satisfy the QS regulation An SPDF is a set of processes that help identify and reducethe number and severity of vulnerabilities in products. An SPDF encompasses all aspects of aproduct’s lifecycle, including design, development, release, support, and decommission.

When reviewing premarket submissions, FDA intends to assess device cybersecurity based on a number of factors, including, but not limited to, the device’s ability to provide and implement the security objectives below throughout the device architecture. The security objectives below generally may apply broadly to devices within the scope of this guidance, including, but not limited to, devices containing artificial intelligence and machine learning (AI/ML) and cloud- based services.

• Authenticity, which includes integrity;

• Authorization;

• Availability;

• Confidentiality; and

• Secure and timely updatability and patchability.

FDA issued a final cybersecurity guidance addressing premarket expectations in 2014 “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices,” and the complementary guidance “Postmarket Management of Cybersecurity in Medical Devices,”13 hereafter referred to as the “Postmarket Cybersecurity Guidance,” in 2016. However, the rapidly evolving landscape, an increased understanding of emerging threats, and the need for capable deployment of mitigations throughout the total product lifecycle (TPLC) warrants an updated, iterative approach to device cybersecurity. The changes since the 2014 guidance are intended to further emphasize the importance of ensuring that devices are designed securely, are designed to be capable of mitigating emerging cybersecurity risks throughout the TPLC, and to more clearly outline FDA’s recommendations for premarket submission information to address cybersecurity concerns.

As cybersecurity is part of device safety and effectiveness, cybersecurity controls established during premarket development should also take into consideration the intended and actual use environment (see Section IV.B.). Cybersecurity risks evolve over time and as a result, the effectiveness of cybersecurity controls may degrade as new risks, threats, and attack methods emerge. In the 510(k) context, FDA evaluates the cybersecurity information submitted and the protections the cybersecurity controls provide in demonstrating substantial equivalence (see section 513(i) of the FD&C Act and 21 CFR 807.100(b)(2)(ii)(B)).2

• A Secure Product Development Framework (SPDF) may be one way to satisfy the QS regulation:

Cybersecurity threats have the potential to exploit one or more vulnerabilities that could lead to patient harm. The greater the number of vulnerabilities that exist and/or are identified over time in a system in which a device operates, the easier a threat can compromise the safety and effectiveness of the medical device. An SPDF is a set of processes that help identify and reduce the number and severity of vulnerabilities in products.

• Designing for security:

When reviewing premarket submissions, FDA intends to assess device cybersecurity based on a number of factors, including, but not limited to, the device’s ability to provide and implement the security objectives below throughout the device architecture. The security objectives below generally may apply broadly to devices within the scope of this guidance, including, but not limited to, devices containing artificial intelligence and machine learning (AI/ML) and cloudbased services.

Security Objectives:

• Authenticity, which includes integrity;

• Authorization;

• Availability;

• Confidentiality; and

• Secure and timely updatability and patchability.

• Transparency:

A lack of cybersecurity information, such as information necessary to integrate the device into the use environment, as well as information needed by users to maintain the medical device system’s cybersecurity over the device lifecycle, has the potential to affect the safety and effectiveness of a device. In order to address these concerns, it is important for device users to have access to information pertaining to the device’s cybersecurity controls, potential risks to the medical device system, and other relevant information.

Vulnerabilities in cybersecurity may represent a risk to the safe and effective operation of

networked medical devices using OTS software. Failure to properly address these vulnerabilities

could result in an adverse effect on public health. FDA recommends that purchasers and users of medical devices that may be subject to a cybersecurity vulnerability contact you with their concerns. The QS regulation, 21 CFR Part 820, applies to software maintenance actions. Under 21 CFR 820.30(g), design validation requires that devices conform to defined user needs and intended uses, including an obligation to perform software validation and risk analysis, where appropriate. Software changes to address cybersecurity vulnerabilities are design changes and must be validated before approval and issuance. Usually not. In general, FDA review is necessary when a change or modification could significantly affect the safety or effectiveness of the medical device. 21 CFR 807.81(a)(3),814.39.

• a. 510(k). For medical devices cleared for market under the 510(k) program, you may refer to our guidance entitled, “Deciding When to Submit a 510(k) for a Change to an Existing Device.” That guidance explains that a new 510(k) submission to FDA is necessary for a change or modification to an existing medical device if:

• The medical device has a new or changed indication for use (e.g., the diseases or conditions the medical device is intended to treat); or

• The proposed change (e.g, modification in design, energy source, chemical composition, or material) could significantly affect the safety or effectiveness of the medical device.

• It is possible, but unlikely, that a software patch will need a new 510(k) submission.3 As with all changes made to devices, you should document the basis of your decisions in the design history file. See 21 CFR 820.3(e), 820.30(j).

• Premarket Approval Application (PMA). For medical devices approved under PMAs (21CFR Part 814), a PMA supplement is required for a software patch if the patch results in a change to the approved indications for use or is deemed by the manufacturer to have an adverse effect on the safety and effectiveness of the approved medical device. 21 CFR 814.39. Otherwise, you should report your decision to apply a software patch to your PMA device to FDA in your annual reports. See 21 CFR 814.39(b), 814.84.

You should maintain formal business relationships with your OTS software vendors to ensure timely receipt of information concerning quality problems and recommended corrective and preventive actions. Because of the frequency of cybersecurity patches, we recommend that you develop a single cybersecurity maintenance plan to address compliance with the QS regulation and the issues discussed in this guidance document. In most cases, therefore, you would not need to report a cybersecurity patch under 21 CFR Part 806 so long as you have evaluated the change and recorded the correction in your records. However, if the software patch affects the safety or effectiveness of the medical device, you should report the correction to FDA, even if a software maintenance plan is in effect.

Healthcare providers should stay informed about cybersecurity risks, apply software updates promptly, and collaborate with manufacturers to address security concerns. Implementing network security measures and providing cybersecurity training for staff are also crucial.

The FDA encourages prompt reporting of cybersecurity incidents related to medical devices. Manufacturers are expected to work with the FDA to address and mitigate security vulnerabilities, and the agency may issue alerts or recalls if necessary.

The FDA’s official website provides detailed information, guidelines, and resources related to medical device cybersecurity. Manufacturers and healthcare professionals can also refer to specific guidance documents released by the FDA for in-depth information.

A large language model is a type of artificial intelligence that has been trained on massive data sets to understand and generate human text in natural language. Examples include OpenAI GPT-3 and similar models.

Security is critical for large language models to prevent misuse, manipulation, or misuse of the model for malicious purposes, such as generating misleading information, generating malicious content, or creating content that violates ethical standards.

Risks include the generation of misinformation, manipulation through biased output, amplification of harmful ideologies, and potential use of the model for malicious activities such as creating realistic-sounding phishing emails or other forms of social engineering attacks.

Safe training involves careful curation and filtering of training data to avoid biased or harmful content. Additionally, adversary training can be used to make the model more resilient to potential attacks.

Yes, large language models can be susceptible to biases present in their training data. Efforts are being made to mitigate these biases, but it is essential to recognize that biases may still exist and should be addressed to ensure fair and ethical use.

Precautions such as content filtering, ethical guidelines and restrictions on model outputs are implemented to minimize the generation of harmful or inappropriate content. Ongoing research is also being conducted to improve content moderation.

Secure deployment includes implementing access control, monitoring model outputs for potential risks, and integrating ethical guidelines into usage policies. Regular updates and patches should be applied to eliminate any vulnerabilities found.

Adversary attacks involve manipulating inputs to fool the model. Although efforts are made to make large language models robust, there is always the risk of adversarial attacks. Regular testing and updating of models can help resolve vulnerabilities.

Organizations establish clear ethical guidelines for the use of large language models, actively engage with the research community and the public for feedback, and iterate on models and policies to ensure responsible and ethical deployment.

Yes, large language models can be used for cybersecurity, such as threat detection and analysis, generating security alerts, and improving natural language understanding in security-related applications.