Webinar: Navigating regulatory waters: Cost-effective risk assessments for financial services

Multiple regulatory frameworks require a risk assessment – NYDFS, FedLine and FedRAMP to name a few – but that doesn’t necessarily mean you need a full ISO/IEC 27005. Join us for our latest webinar as we break down and detail what you really need for a cost-effective and compliant risk assessment.

In this session, our experts – Miguel Gutierrez and Richards Suls – will share their insights on recent framework developments and break down a risk assessment exercise for a financial services company using Reversec’s methodology.

Why Watch?

By watching this webinar, you will benefit from:

  • An enhanced understanding of the specific risk assessment requirements for key regulatory requirements
  • A practical knowledge of what a compliant risk assessment looks like without the need for a full ISO 27005
  • Learning from a real-life example of a risk assessment exercise for a financial services organization
  • Having your specific questions answered during our interactive Q&A session

Speakers:
Richard Suls, Senior Security & Risk Management Consultant
Miguel Gutierrez, Host & Security Consultant

Related content

Webinars

NYDFS 500 Cybersecurity Regulation Enforcement Actions: Causes and Consequences

September 5, 2024
NYDFS 500 Cybersecurity Regulation Enforcement Actions: Causes and Consequences
Webinars

NYDFS 500: Simplifying the second amendment

June 13, 2024
NYDFS 500: Simplifying the second amendment
Whitepapers

NYDFS 500 – Plan for stronger cybersecurity compliance

July 1, 2024
NYDFS 500 – Plan for stronger cybersecurity compliance
Our thinking

NYDFS 500 vs. DORA: Comparison for European financial institutions

February 16, 2024
NYDFS 500 vs. DORA: Comparison for European financial institutions
Whitepapers

NYS DFS 500 amendment explainer

May 25, 2024
NYS DFS 500 amendment explainer

Webinar: Navigating the NYDFS Cybersecurity Regulation – Q&A and live demo with our compliance experts

The New York State Department of Financial Services (NYDFS) Cybersecurity Regulation has presented financial intuitions operating in New York with even greater challenges in maintaining their compliance. Since it was enacted in 2017, NYDFS has issued numerous enforcement action and monetary penalties.

In our earlier webinars we have discussed the requirements of the NYDFS’ Second Amendment and looked at the regulatory enforcement actions that have already been issued.

In our latest webinar, our experts – John Jarrold, Richard Suls and Miguel Gutierrez – took one section of the NYDFS Cybersecurity Regulation and applied it to an anonymized company to show how we can help ensure your organization remains compliant and avoid enforcement actions.

Speakers:
John Jarrold, Senior Security & Risk Management Consultant
Richard Suls, Senior Security & Risk Management Consultant
Miguel Gutierrez, Host & Security Consultant

Watch the webinar

Related content

Webinars

NYDFS 500 Cybersecurity Regulation Enforcement Actions: Causes and Consequences

September 5, 2024
NYDFS 500 Cybersecurity Regulation Enforcement Actions: Causes and Consequences
Webinars

NYDFS 500: Simplifying the second amendment

June 13, 2024
NYDFS 500: Simplifying the second amendment
Whitepapers

NYDFS 500 – Plan for stronger cybersecurity compliance

July 1, 2024
NYDFS 500 – Plan for stronger cybersecurity compliance
Our thinking

NYDFS 500 vs. DORA: Comparison for European financial institutions

February 16, 2024
NYDFS 500 vs. DORA: Comparison for European financial institutions
Whitepapers

NYS DFS 500 amendment explainer

May 25, 2024
NYS DFS 500 amendment explainer

NYDFS 500 Cybersecurity Regulation Enforcement Actions: Causes and Consequences

The New York State Department of Financial Services (NYDFS) enacted its cybersecurity regulation, 23 NYCRR 500, in 2017. Since then, the department has issued numerous enforcement actions around 23 NYCRR 500 , with monetary penalties averaging several million dollars.

We performed an in-depth analysis of the consent orders published by NYDFS to understand the causes and consequences of these actions.

Join our experts John Jarrold, Richard Suls and Miguel Gutierrez as they discuss their findings and provide insights to help your organization minimize the risk of NYDFS enforcement actions.

Discussion topics include:

  • Common deficiencies that have led to enforcement actions
  • Apparent changes in the NYDFS enforcement strategy
  • Strategies to avoid or mitigate the impact of enforcement actions

Speakers:

John Jarrold, Senior Security & Risk Management Consultant
Richard Suls, Senior Security & Risk Management Consultant
Miguel Gutierrez, Host & Security Consultant

Related content

Webinars

NYDFS 500: Simplifying the second amendment

June 13, 2024
NYDFS 500: Simplifying the second amendment
Our thinking

NYDFS 500 cybersecurity regulation: What’s changed?

August 31, 2023
NYDFS 500 cybersecurity regulation: What’s changed?
Whitepapers

NYDFS 500 – Plan for stronger cybersecurity compliance

July 1, 2024
NYDFS 500 – Plan for stronger cybersecurity compliance
Our thinking

NYDFS 500 vs. DORA: Comparison for European financial institutions

February 16, 2024
NYDFS 500 vs. DORA: Comparison for European financial institutions

NYDFS 500 – Plan for stronger cybersecurity compliance

What recent NYDFS 500 compliance updates mean for regulated entities


The NYDFS 500 Cybersecurity Regulation, a dynamic framework, is designed to safeguard New York’s financial institutions from the escalating threat of cybercrime. Enforced by the New York Department of Financial Services, the regulation mandates stringent cybersecurity measures, including risk assessments, designation of a qualified CISO, and comprehensive incident response protocols. Since its inception in 2017, the regulation has evolved significantly, with recent amendments introducing heightened requirements to address common cyber vulnerabilities. The report delves into the enforcement actions taken by NYDFS, highlighting key compliance challenges and offering strategic recommendations to fortify cyber security defenses.

It includes:

  • Top 10 List of most impactful new requirements to the covered entities.
  • Analyses the types of security incidents and the sections of the regulation that were found to have been violated.  

WHITEPAPER

NYDFS 500 – Plan for stronger cyber security compliance

Download

Related content

Our thinking

NYDFS 500 cybersecurity regulation: What’s changed?

August 31, 2023
NYDFS 500 cybersecurity regulation: What’s changed?
Our thinking

NYDFS 500 vs. DORA: Comparison for European financial institutions

February 16, 2024
NYDFS 500 vs. DORA: Comparison for European financial institutions
Webinars

NYDFS 500: Simplifying the second amendment

June 13, 2024
NYDFS 500: Simplifying the second amendment

NYDFS 500: Simplifying the second amendment

Join our experts as they summarize the changes in the Second Amendment of the NYDFS Cybersecurity Regulation, or 23 NYCRR 500.

The New York State Department of Financial Services (NYDFS) cyber security regulation enacted in 2017 has resulted in numerous enforcement actions and monetary penalties averaging several million dollars. Amendments to the regulation have presented financial institutions operating in New York with even greater challenges in maintaining their compliance. 

The Second Amendment to 23 NYCRR 500 added even more stringent requirements, intended to address common cyber weaknesses that they have identified since 2017.

During this webinar, our experts review and summarize the key changes to the Second Amendment, offering recommendations and advice on how organizations can ensure they remain compliant.

Speakers:
John Jarrold, Senior Security & Risk Management Consultant
Richard Suls, Senior Security & Risk Management Consultant
Miguel Gutierrez, Host & Security Consultant

Related content

Webinars

Building secure LLM apps into your business

April 11, 2024
Building secure LLM apps into your business
Our thinking

Prompt injections could confuse AI-powered agents

May 17, 2024
Prompt injections could confuse AI-powered agents

Insights into the NIS2 Directive

What is NIS2?

NIS2 expands the scope of its predecessor, bringing critical sectors like supply chains, food production, and public administration under its protective wing. It introduces standardized incident reporting, ensuring that threats are managed and monitored proactively.

The digital landscape is evolving rapidly, and the complexity and volume of cybersecurity threats are rising. Recognizing the critical need for enhanced security measures, the European Union took a pioneering step six years ago by introducing the first Network and Information Security (NIS) Directive, the first EU-wide regulation on cybersecurity. This landmark legislation was a foundational framework, establishing baseline security protocols across various industries. Fast forward to today, the landscape has transformed, necessitating a more robust and comprehensive approach to cybersecurity – enter NIS2.

Building on the groundwork laid by its predecessor, NIS2 is not just an update; it’s a significant expansion of scope and ambition to address the evolving cyber threat landscape. One of the key enhancements is the inclusion of supply chains, a critical area of vulnerability in today’s interconnected digital ecosystem. Moreover, NIS2 sets out to standardize incident reporting, creating a uniform framework that enhances nationwide visibility into cyberattacks and their impact across different sectors.

A notable shift in NIS2 is its proactive stance towards security monitoring. The directive mandates active surveillance of IT environments to detect anomalies and potential threats, moving beyond passive defense mechanisms. Additionally, it brings company management into the fold of cybersecurity, establishing accountability and integrating cybersecurity management into the broader corporate governance structure.

The implications of NIS2

For organizations, the transition to NIS2 brings a host of new responsibilities and challenges. The directive encompasses a broader range of sectors, including previously overlooked areas such as public information networks, food production, and public administration. Moreover, it introduces stringent reporting requirements, with the first notification of incidents required within 24 hours and a detailed analysis and action plan due within a month.

NIS2 also emphasizes the importance of supply chain security, recognizing the cascading effects that vulnerabilities in one part of the supply chain can have on others. This holistic approach extends to IT best practices, requiring organizations to adopt a comprehensive security posture that covers everything from asset management to encryption and human resources.

Preparing for NIS2

With the implementation deadline looming and no transition period offered, organizations must act swiftly to align their security practices with NIS2 requirements. This involves conducting thorough risk analyses, establishing incident management capabilities, and ensuring all technical measures, from patch management to multi-factor authentication, are in place.

Collaboration and shared expertise will be vital to navigating this transition. For instance, leveraging existing cybersecurity frameworks such as ISO 27001 or the NIST Cybersecurity Framework can provide a solid foundation for meeting NIS2 requirements. Furthermore, ongoing staff training and awareness programs are essential to foster a culture of security and preparedness across all levels of the organization.

Conclusion

NIS2 represents a significant step in the EU’s efforts to bolster cybersecurity defenses. By expanding the scope of regulation, standardizing reporting, and emphasizing proactive security monitoring, NIS2 aims to create a more resilient digital infrastructure capable of withstanding the threats of the modern world. For organizations, the journey towards compliance may be challenging, but it is a critical investment in the security and reliability of their operations and, by extension, the broader digital ecosystem.

As the deadline approaches, the message is clear: the time to act is now. By embracing the spirit of NIS2, organizations can comply with the new directive and strengthen their defenses against the ever-evolving threats of the digital age.

Related content

Webinars

Cracking the NIS2 Code: Compliance Solutions and Practical Advice

May 22, 2024
Cracking the NIS2 Code: Compliance Solutions and Practical Advice
Our thinking

NYDFS 500 vs. DORA: Comparison for European financial institutions

February 16, 2024
NYDFS 500 vs. DORA: Comparison for European financial institutions
Our thinking

What is Attack Path Mapping

April 17, 2024
What is Attack Path Mapping

NYS DFS 500 amendment explainer

What the NYS DFS 500 amendment means for regulated entities

The New York State Department of Financial Services (NYS DFS) is responsible for ensuring the safety and soundness of financial institutions, protecting consumers, and promoting the growth of the NY financial services sector. In 2023, NYS DFS is rolling out significant revisions to its Cybersecurity Regulation (23 NYCRR Part 500).

These changes, known as the Second Amendment, address gaps in the original regulation, aiming to enhance consumer protection and strengthen the financial system against sophisticated cyber threats. Non-compliance can lead to hefty fines, with average penalties around $3 million.

The report breaks down the new requirements and offers strategic guidance on how to stay compliant. Download it to understand the implications of the Second Amendment and learn practical steps to safeguard your organization against regulatory actions and cyber threats.

WHITEPAPER

NYS DFS 500 amendment explainer

Download

Cracking the NIS2 Code: Compliance Solutions and Practical Advice

In this webinar we offer practical guidance to ensure that your organization is prepared to meet NIS2 compliance requirements.

Our expert panel will address frequently asked questions surrounding NIS2 compliance, covering everything from regulatory obligations to actionable steps for implementation.

Key topics and questions on NIS2 compliance requirements:

  • Common challenges and pitfalls in achieving NIS2 compliance
  • Industry specific nuances
  • Practical strategies and actionable steps for compliance implementation
  • What are the potential consequences of non-compliance?
  • How will the NIS2 impact countries operating internationally? 
  • How will NIS2 affect cross-border data transfers?  
  • How is NIS2 compliance audited?
  • Will there be any government assistance or resources available to help companies comply with NIS2?

Don’t miss this opportunity to have your questions answered about NIS2 compliance and take proactive steps to safeguard your organization.

Speakers:
Albert Koubov Gonzalez, Security Consultant
Antti Laatikainen, Principal Consultant
Janne Kauhanen, Cyber Host & Account Director

Watch now:

https://www.youtube.com/watch?v=5jzb_Jh6wDI
Connecting the dots: Shared requirements of ISO 27001, NIS2, DORA, and NYDFS
Whitepapers

Connecting the dots: Shared requirements of ISO 27001, NIS2, DORA, and NYDFS

Read more
May 23, 2024

Related content

Webinars

Building secure LLM apps into your business

April 11, 2024
Building secure LLM apps into your business
Our thinking

Prompt injections could confuse AI-powered agents

May 17, 2024
Prompt injections could confuse AI-powered agents

Striking the balance – EU AI Act and its impact on cybersecurity

WithSecure’s response to the EU AI Act and its impact on cyber security

Introduction

The European Union’s proposed AI Act has ignited a debate on the potential impact of AI regulation on innovation and, more specifically, its implications for the cybersecurity industry. Sceptics argue that stringent regulation might stifle innovation, while proponents assert that it is crucial to mitigate the risks associated with AI technologies. Balancing innovation and regulation is a delicate task, especially in the realm of cybersecurity where the implications of AI are profound.

Would regulation kill AI?

The concern that AI regulation might stifle innovation and allow non-Western countries to gain dominance in AI is a valid one. The AI industry is currently in an industrial arms race, with large technological players vying for supremacy. However, innovation should not come at the cost of security, ethics, and the protection of fundamental human rights.

While it’s true that overly restrictive regulations could slow down the industry, it’s equally essential to recognize that AI technologies have far-reaching consequences. Without proper regulation, we risk creating a Wild West scenario in which AI is developed and deployed without adequate safeguards. This could lead to privacy breaches, job losses, and potential manipulation of public opinion.

Why do we need regulation?

AI regulation is an essential step, but it carries its own risks. If regulation is too stringent, it can stifle innovation and create a false sense of control. Limiting market access may also lead to a skewed view of control, as companies may still evade regulations, leading to a revolving door of industry players, lobbyists, and politicians influencing AI regulation.

The consequences of getting AI wrong are substantial. Unlike previous technologies, AI has the potential to impact society and industry in ways that cannot be easily reversed. AI can significantly affect the economy, societal structures, and personal lives. Thus, the stakes are high, and we must approach AI with a greater degree of caution and responsibility.

The risks that warrant the need for regulation in AI include:

Lack of Transparency: Many AI systems are trained on biased source material, leading to potential bias in their outputs. Ensuring transparency in how AI systems handle these biases is crucial.

Invasion of Privacy: AI can be used to extract data and make inferences that may violate privacy laws, putting individuals at risk.

Job Displacement: AI’s mass automation capabilities could lead to job losses in various industries. Regulations should address the impact on employment.

Market Inequality: Not all companies have the resources to compete in the AI space, leading to market monopolies.

Societal Division: If only certain countries can afford AI technologies, it may exacerbate global inequalities.

Manipulation of Opinion: AI can propagate harmful biases and “truths” through media, undermining public discourse.

Violation of Human Rights: AI systems can perpetuate profiling, racism, and sexism, violating fundamental human rights.

Security Risks: AI can be exploited for cyberattacks and pose threats to cybersecurity.

Identity Theft: Users should have the right to know when they are interacting with AI systems to prevent identity theft and impersonation.

Patent Trolling: Regulatory measures should prevent the rise of patent troll companies exploiting AI creators.

It’s noteworthy that leading AI corporations are testifying to governments and advocating for regulation. However, given the complexity of AI systems and the many stakeholders involved, some scepticism about the feasibility of comprehensive regulation is warranted.

Certain industries have become so complex and resistant to regulation that the call for regulation may seem like a double bluff. Nonetheless, there is a genuine need for some level of involvement to ensure that AI is developed and used responsibly. The stakes are high, and we cannot afford to get AI wrong, as we have with other technologies like IoT and social media.

The risks that warrant the need for regulation in AI include:

  1. Lack of Transparency: Many AI systems are trained on biased source material, leading to potential bias in their outputs. Ensuring transparency in how AI systems handle these biases is crucial.
  2. Invasion of Privacy: AI can be used to extract data and make inferences that may violate privacy laws, putting individuals at risk.
  3. Job Displacement: AI’s mass automation capabilities could lead to job losses in various industries. Regulations should address the impact on employment.
  4. Market Inequality: Not all companies have the resources to compete in the AI space, leading to market monopolies.
  5. Societal Division: If only certain countries can afford AI technologies, it may exacerbate global inequalities.
  6. Manipulation of Opinion: AI can propagate harmful biases and “truths” through media, undermining public discourse.
  7. Violation of Human Rights: AI systems can perpetuate profiling, racism, and sexism, violating fundamental human rights.
  8. Security Risks: AI can be exploited for cyberattacks and pose threats to cybersecurity.
  9. Identity Theft: Users should have the right to know when they are interacting with AI systems to prevent identity theft and impersonation.
  10. Patent Trolling: Regulatory measures should prevent the rise of patent troll companies exploiting AI creators.

It’s noteworthy that leading AI corporations are testifying to governments and advocating for regulation. However, given the complexity of AI systems and the many stakeholders involved, some scepticism about the feasibility of comprehensive regulation is warranted.

Certain industries have become so complex and resistant to regulation that the call for regulation may seem like a double bluff. Nonetheless, there is a genuine need for some level of involvement to ensure that AI is developed and used responsibly. The stakes are high, and we cannot afford to get AI wrong, as we have with other technologies like IoT and social media.

Open-Source AI as an antidote

If the main threats posed by an oligarchy of AI players are opaqueness, bias and a monolithic railroading of the tech industry, then open source might be the antidote to these and other threats. The open-source movement has always stood for taking back power from large for-profit corporations and to make sure that open and/or freely available alternatives are possible when it comes to what one wants to do with a computer or device that runs any kind of software.

The open-source movement could play a continued essential role in democratizing AI, preventing an unhealthy concentration of power, and ensuring that the technology is developed and used responsibly. A few of the advantages of having open-source AI alternatives when it comes to the Large Language Models, the source data as well as the weights and structure:

Transparency and Trust: Proprietary AI systems are opaque and make it hard for outsiders to understand their workings, biases or vulnerabilities. Open-source projects are by their very nature open to scrutiny. This transparency can lead to greater trust among the public, developers, and researchers.

Collaborative Development: Open source can be used to teach how AI systems work and how to make them better. It encourages a community-driven approach where a global community of developers, researchers and enthusiasts can contribute to and enhance the technology. This diverse input can lead to more robust, versatile, and efficient AI systems.

Avoiding Monopolies: By keeping at least a few core AI technologies open source, the barriers to entry for startups and individual developers are significantly reduced. This promotes a more competitive landscape, preventing a few companies from holding a disproportionate amount of control and influence over the technology and its applications.

Ethical Standards: The open-source community often promotes ethical standards and best practices. By working together, the community can ensure that AI is developed and used responsibly, considering societal impacts, fairness, and human rights. E.g. certain models can never be used for weapons systems or social credit score systems. This also means that governments and regulatory bodies can better understand, assess, and regulate AI technologies. This can lead to more informed policy decisions that consider public interest and safety.

Global Inclusivity: Not only that, it ensures that every country or organization that does not have the resources to develop AI from scratch can benefit from AI advancements. This means AI technology can be made accessible to a broader range of people, irrespective of their geographical location or financial capabilities.

Security: While it might seem counterintuitive, open-source projects can be more secure. The vast number of eyes on the code means vulnerabilities can be spotted and rectified faster. The “many eyeballs” theory suggests that the more people who can see and test a set of code, the more likely any flaws will be caught and hopefully addressed quickly.

Reversec’s recommendations for EU private and public organizations

The EU AI Act presents a critical opportunity to shape the future of AI and address its potential risks. While concerns about stifling innovation are valid, we must strike a balance to ensure the responsible development and deployment of AI.

Open-source AI solutions, transparency, and ethical standards can play a pivotal role in democratizing AI while keeping it secure and accountable. As the AI landscape continues to evolve, it is essential to prioritize cybersecurity and privacy without unduly hindering progress in this transformative field.

To address the cybersecurity challenges presented by EU AI Act, several recommendations are warranted:

  1. Cybersecurity Problems of AI: The AI industry must focus on addressing data privacy issues, biases, and model explainability to enhance AI cyber security.
  2. Cybersecurity Implications of the EU AI Act: The EU AI Act is a positive step, but it should be carefully crafted to avoid limiting the effectiveness of cybersecurity measures.
  3. Pros and Cons for the cybersecurity Industry: The EU AI Act will create transparency and restrict excess data gathering, but it may also create a gap between defenders and malicious actors.
  4. Harnessing AI in cybersecurity: The cyber security industry should leverage AI, particularly GAI and LLMs, to improve threat detection and response, and educate non-experts in safe practices.

We strongly recommend that all public and private organizations within the EU fully utilize the two-year implementation period provided for the development and deployment of AI standards for high-risk systems. This period, mandated by the EU AI Act, presents a strategic opportunity to advance beyond mere security compliance and foster a robust AI security culture within organizations.

To effectively leverage this opportunity, we suggest the following steps:

  1. Develop a Comprehensive AI Risk Model: Align with the EU AI Act by defining clear business objectives, mapping AI use cases, identifying systems that constitute high risk, and prioritizing AI assets for protection. This step should serve as a crucial link between your business strategy and the technical development of AI, ensuring a cohesive approach to AI deployment.
  2. Conduct Thorough Threat Modelling for High-Risk AI Initiatives: Adhere to the EU AI Act by meticulously documenting and reviewing system architectures. Identify the requirements for human oversight, as well as the data and model controls necessary to thwart potential attackers. Utilize this process as an opportunity to educate technical teams on security best practices, integrating these practices into the workflows of developers and data scientists.
  3. Simulate AI Cyber Threats: Confirm the efficacy of the detection and response controls of your models and infrastructure. It’s essential to test the robustness and reliability of AI systems proactively before they are targeted by real-world attackers. This proactive approach not only ensures compliance with current regulations and forthcoming AI cybersecurity standards but also prepares your organization for future threats and challenges in the AI security landscape.

By following these steps, organizations can not only comply with current regulations but also position themselves at the forefront of AI security and innovation.

In the ever-changing landscape of AI and cybersecurity, the EU AI Act stands as a significant milestone. While it poses challenges, it also offers a unique opportunity to create a regulatory framework that balances innovation with accountability.

By addressing the risks associated with AI and fostering responsible innovation, the cybersecurity industry can harness the potential of AI technologies while ensuring a secure digital future for all. Collaboration, transparency, and ethical standards should be at the core of this transformative journey, paving the way for a harmonious coexistence between innovation and regulation in the realm of AI-driven cybersecurity.

Related content

Webinars

Building secure LLM apps into your business

April 11, 2024
Building secure LLM apps into your business
Our thinking

Prompt injections could confuse AI-powered agents

May 17, 2024
Prompt injections could confuse AI-powered agents

NYDFS 500 vs. DORA: Comparison for European financial institutions

A Comparison for European financial institutions

This is a comprehensive comparison of the NYDFS 500 and DORA to equip European financial institutions with the essential knowledge to prepare for DORA and the Digital Operational Resilience Act.

It aligns efforts to meet both these regulations, which are subject to NYDFS oversight and are of utmost importance.

Before reading, you should be familiar with DORA, a new European Union regulation designed to protect the financial sector against threats and disruption to its information and communication technologies.

The New York State Department of Financial Services (NYDFS) is a regulatory agency that oversees financial institutions operating in New York. Its primary responsibilities include:

  • Ensuring the safety and soundness of financial institutions
  • Protecting consumers
  • Fostering the growth of the NY financial services sector

NYDFS-covered entities encompass banks, insurance companies, mortgage lenders, and other financial institutions.

In March 2017, the NYDFS enacted a Cybersecurity Regulation (23 NYCRR Part 500), commonly known as NYDFS 500. The intent was to ensure covered entities establish and maintain strong cybersecurity practices to protect consumers and the financial system’s stability against the relentless increase in attacks by cyber criminals targeting the financial services sector.

In November 2023, NYDFS amended the regulation, adding substantial new requirements. This update was intended to address changes in the cybersecurity threat landscape and the increasing sophistication and frequency of attacks.

The amendment was also designed to mitigate common weaknesses, which NYDFS believed to be the root cause of security incidents that affected covered entities over the six years since the original regulation was enacted.

Non-compliance with NYDFS 500 can have severe financial implications. Since 2017, NYDFS has imposed fines on at least 16 covered entities, with an average settlement of $2.2 million. Larger institutions have faced penalties in the $4–5 million range. These figures are a stark reminder of the importance of strict adherence to NYDFS 500.

The following sections meticulously compare each aspect of NYDFS 500 to DORA, identifying areas of overlap, additional requirements in NYDFS 500, and other key differences. This detailed comparison ensures that you, as a financial institution, have all the necessary information to comply with both regulations.

500.2 Cybersecurity Program

This section requires covered entities to develop and maintain a cybersecurity program that includes:

  • Risk Identification and Assessment 
  • Defensive Infrastructure Implementation 
  • Cyber Security Event Detection, Response, and Recovery 
  • Regulatory Reporting 

It also requires larger intuitions—designated ‘Class A Companies’—to conduct independent audits of their programs and to make program documentation available to NYDFS upon request. 

In DORA, the ICT Risk Management Framework (RMF) is analogous to the Cyber Security Program in NYDFS 500 and includes the exact requirements as NYDFS 500 except for Regulatory Reporting: 

  • Risk Identification and Assessment [Article 8(2)] 
  • Defensive Infrastructure [Article 7] 
  • Detection [Article 10], and Response and Recovery [Article 11] 

Like NYDFS 500, DORA also requires regular audits of the RMF [Article 6(6)], and documentation must be submitted to regulators upon request [Article 6(5)].

500.3 Cybersecurity Policy 

NYDFS directly specifies 15 areas that policies and procedures must address: 

  1. Information security 
  2. Data governance, classification, and retention 
  3. Asset inventory, device management, and end-of-life management 
  4. Access controls, including remote access and identity management 
  5. Business continuity and disaster recovery planning and resources 
  6. Systems operations and availability concerns 
  7. Systems and network security and monitoring 
  8. Security awareness and training 
  9. Systems and application security, and development and quality assurance 
  10. Physical security and environmental controls 
  11. Customer data privacy 
  12. Vendor and third-party service provider management 
  13. Risk assessment 
  14. Incident response and notification 
  15. Vulnerability management

A senior officer or the governing body must review and approve these policies annually. 

DORA also requires covered entities to put policies in place [Article 5(2)(b)] and mentions some specific policies throughout the regulation, but the requirements are less direct and prescriptive. The following maps policies required by NYDFS 500 to those specified by DORA:

  1. Information security [Article 9(4)(a))]
  2. Data governance, classification, and retention [not mentioned] 
  3. Asset inventory, device management, and end-of-life management [not mentioned] 
  4. Access controls, including remote access and identity management [Article 9(4)(c-d)], Article 15(3(b))] 
  5. Business continuity and disaster recovery planning and resources [Business Continuity: Article 11(1)] 
  6. Systems operations and availability concerns [not mentioned] 
  7. Systems and network security and monitoring [not mentioned] 
  8. Security awareness and training [not mentioned] 
  9. Systems and application security and development and quality assurance [not mentioned] 
  10. Physical security and environmental controls [not mentioned] 
  11. Customer data privacy [not mentioned] 
  12. Vendor and third-party service provider management [not mentioned] 
  13. Risk assessment [not mentioned] 
  14. Incident response and notification [Incident classification: Article 24(5)] 
  15. Vulnerability management [Patch management: Article 9(4)(f))] 

DORA doesn’t explicitly state that the management body must approve policies or that they need to be periodically reviewed, except for the Business Continuity policy [Article 5(2)(e))].

500.4 Cybersecurity Governance

NYDFS 500 requires covered entities to designate a qualified CISO. The CISO may be from a third-party service provider or affiliate, but the entity retains compliance responsibility. 

The CISO must give an annual report on the cybersecurity program to the senior governing body, which covers the following: 

  • Security Defenses 
  • Policy and Procedures 
  • Risk Assessment 
  • Program Effectiveness 
  • Cyber security Incidents 
  • Gap Remediation 

In the interim, the CISO must also promptly report to the senior governing body on any cybersecurity issues, security events, or significant changes to the program. 

The senior governing body is required to exercise oversight of cybersecurity risk management and has the following responsibilities:

  • Possess sufficient understanding of cybersecurity matters for effective oversight 
  • Direct development and maintenance of the cybersecurity program 
  • Allocate adequate resources for the program 
  • Regularly review cybersecurity reports 

Unlike NYDFS 500, DORA doesn’t include a specific requirement for annual reporting on the state of the RMF to the management body. 

DORA’s only explicitly defined reporting requirements specific to the management body are for senior staff to report at least yearly to the management body on lessons learned from penetration testing [Article 13(5)] and to inform the management body of major ICT-related incidents [Article 17(3(e))]. 

DORA also requires the RMF to be reviewed at least yearly but doesn’t specify management body involvement [Article 6(5)].

Under DORA, the management body is also ultimately responsible for the RMF [Article 5(2(a))] and has all the responsibilities defined in NYDFS 500 except for regularly reviewing cybersecurity reports: 

  • Keep up to date with sufficient cybersecurity knowledge and skills [Article 5(4)] 
  • Define, approve, oversee, and be responsible for RMF implementation [Article 5(2)] 
  • Allocate appropriate budget [Article 5(2(g))] 

500.5 Vulnerability Management

NYDFS vulnerability management requirements include: 

  • Perform annual internal and external penetration testing by a qualified internal or external party. 
  • Perform automated scans of systems and manual review of systems not covered by automated scans periodically and after material changes. 
  • Implement a process to stay informed of new security vulnerabilities. 
  • Remediate vulnerabilities in a timely, risk-based manner. 

DORA has equivalent requirements for penetration testing but is less specific than NYDFS 500 regarding vulnerability scans and patch management. 

About penetration testing: 

  • DORA requires all testing to be performed annually, which includes penetration testing [Article 24(6)]. 
  • DORA doesn’t explicitly state whether testing needs to be from an internal or external perspective, while NYDFS 500 requires both. 
  • DORA doesn’t specifically require ‘qualified’ testers for penetration testing. 

Please note the above statements relate to Article 25 – Testing of ICT tools and systems, which includes penetration testing. DORA has more stringent requirements for Threat-Led Penetration Testing (TLPT) [Articles 26 & 27], but TLPT involves red teaming, which isn’t explicitly required by NYDFS 500. 

For vulnerability scanning, the ‘Testing of ICT Tools and Systems’ article includes ‘vulnerability assessments and scans’ in a list of ‘appropriate tests’ [Article 25(1)]. DORA also requires remediation of vulnerabilities [Article 24(5)]. Still, it doesn’t explicitly state that it must be timely, like NYDFS 500, and doesn’t mention the manual review of unscannable systems as required by NYDFS 500.  

Concerning monitoring for new vulnerabilities, the ‘Learning and Evolving’ article states that covered entities must have ‘capabilities and staff to gather information on vulnerabilities and cyber threats’ [Article 13(1)].

500.6 Audit Trail

This section requires covered entities to securely maintain systems that collect audit trails designed to detect and respond to cybersecurity events and can reconstruct material financial transactions. 

The security event audit trails must be retained for three years, and the financial transaction logs must be retained for five years. 

DORA doesn’t define requirements specific to collecting and managing audit logs.

500.7 Access Privileges and Management

This section requires covered entities to do the following: 

  • Limit user access (i.e., the principle of least privilege) 
  • Review (recertify) user access 
  • Terminate user access when they leave the organization 
  • Define a password policy 
  • Automatically block common passwords 
  • Implement a privileged access management solution 
  • Restrict the number of privileged accounts 
  • Limit privileged account usage 
  • Monitor privileged access activity 
  • Disable remote access protocols 

DORA is much less prescriptive in the access management domain. In comparison with NYDFS 500: 

  • Limiting user access is also a requirement in DORA [Article 9(4(c))]. 
  • Reviewing user access isn’t directly mentioned but may be implied in a statement that entities must establish policies, procedures, and controls to ensure a sound administration of access rights [Article 9(4(c))]. 
  • Terminating leavers’ access isn’t directly mentioned but can also be implied in the statement above. 
  • DORA doesn’t define any specific requirements for passwords. 
  • DORA doesn’t require entities to implement a privileged access management solution or include specific requirements around privileged accounts. 
  • DORA doesn’t require disabling or restricting the use of remote access protocols.

500.8 Application Security

NYDFS 500 requires entities to ensure secure development practices for in-house developed applications and assess the security of externally developed applications. It also requires the CISO to review the associated procedures, guidelines, and standards at least annually. 

Source code reviews are included in DORA’s list of appropriate tests under ‘Testing of ICT tools and systems’ [Article 25(1)], but secure software development isn’t mentioned further. 

Concerning externally developed applications, DORA requires that third-party service providers participate and fully cooperate with the entity’s Threat-Led Penetration Testing (TLPT) [Article 30(3)(d)].

500.9 Risk Assessment

NYDFS 500 requires covered entities to conduct risk assessments of information systems at least annually and whenever a change in the business or technology causes a material change to the covered entity’s cyber risk. 

The assessment must account for risks particular to the covered entity’s business operations, technological developments, and evolving threats and explain how the identified risks will be addressed. 

The assessment must be performed according to written policies and procedures which cover: 

  • Risk evaluation and categorization 
  • Assessment of the confidentiality, integrity, security, and availability of information systems and nonpublic information 
  • Requirements for risk treatment (e.g., mitigate or accept) 

DORA also requires risk assessments to be performed annually [Article 8(2)] and following significant changes to information systems or business functions [Article 8(3)]. 

Like NYDFS 500, DORA also directs entities to identify risks relevant to supported business functions and consider the impact of technological developments and new cyber attacks [Article 13(7)]. 

DORA doesn’t explicitly mention risk assessment procedures. Concerning the elements that NYDFS 500 specifies to be included in these procedures, DORA includes risk classification [Article 18(2)] but doesn’t touch on risk treatment.

500.10 Cybersecurity Personnel and Intelligence

This section requires covered entities to have qualified cybersecurity personnel, give them sufficient training to address security risks, and verify that they maintain current knowledge of cybersecurity threats and countermeasures. 

NYDFS 500 allows covered entities to use qualified personnel from an affiliate or third-party service provider. 

DORA doesn’t explicitly require qualified cybersecurity personnel but mentions that independent auditors must possess sufficient cyber risk knowledge, skills, and expertise [Article 6(6)]. 

DORA requires Security Awareness Training (SAT) for all employees [Article 13(6)]. Although it doesn’t mention specific or additional training for cybersecurity personnel, it says the training should have a ‘level of complexity commensurate to the remit of employee functions’. 

DORA requires entities to keep up-to-date with the latest cyber risk management processes [Article 13(7)]. Still, it doesn’t include verifying that individual personnel comply with this directive. 

Concerning NYDFS 500 allowing the use of qualified third-party personnel to manage cybersecurity, DORA doesn’t mention this but also doesn’t prohibit it.

500.11 Third-Party Service Provider Security Policy

Regarding third-party risk management, NYDFS requires that covered entities: 

  • Identify (inventory) third parties 
  • Perform third-party risk assessments 
  • Define minimum cybersecurity practices necessary for third parties to meet 
  • Conduct due diligence 
  • Perform continuous monitoring 

The regulation mentions explicitly that due diligence must cover the third party’s access control and encryption practices. 

Additionally, entities must ensure that third parties give representations and warranties on their cybersecurity policies and procedures and are required to give notification if a cybersecurity event directly impacts the entity’s information systems. 

The following NYDFS 500 requirements are also included in DORA: 

  • Third-party Identification [Article 8(5)] 
  • Risk Assessment [Article 28(4(c))] 
  • Due Diligence [Article 28(4)] 
  • Continuous Monitoring [Article 28(6)] 

DORA doesn’t explicitly include the following third-party risk management requirements contained in NYDFS 500: 

  • Notification in the event of a security incident 
  • The concept of Minimum Cybersecurity Practices 
  • Specific mention that access control and encryption must be covered in due diligence 
  • Representations and warranties on the third party’s cybersecurity policies and procedures

500.12 Multi-Factor Authentication

NYDFS 500 requires MFA for ‘any individual accessing any information systems of a covered entity’ unless the CISO approves in writing the use of reasonably equivalent or more secure compensating controls. 

DORA doesn’t include this requirement.

500.13 Asset Management and Aata Retention Requirements

NYDFS 500 requires covered entities to maintain a complete, accurate, documented asset inventory per written policies and procedures. It also specifies required inventory data fields (owner, location, classification or sensitivity, support expiration date, and recovery time goal). 

The inventory must be validated and updated at a defined but non-prescribed frequency. 

Additionally, this section requires covered entities to regularly and securely dispose of unnecessary nonpublic information unless its retention is required by law or disposal is impractical due to how the data is maintained. 

DORA requires financial entities to identify all information assets [Article 8(4)]. Critical assets must be labeled, but no other required fields are specified. The inventory must be updated periodically following significant changes [Article 8(6)]. 

DORA doesn’t include any requirements around data disposal.

500.14 Monitoring and Training

This section requires covered entities to: 

  • Monitor user activity to detect unauthorized access or tampering with nonpublic information. 
  • Protect against malicious code, including monitoring and filtering web traffic and emails to block malicious content. 
  • Give annual cyber security awareness training for all personnel that reflects the entity’s risk assessment and covers social engineering. 

Additionally, class A companies are required to implement: 

  • An endpoint detection and response (ERD) solution to monitor anomalous activity 
  • A solution that centralizes logging and security event alerting (i.e., SIEM) 

DORA doesn’t require user activity monitoring or specifically mention malware or web/email filtering. Like NYDFS, DORA also requires yearly Security Awareness Training [Article 13(6)] but doesn’t specify that it needs to align with the entity’s risk assessment or cover social engineering. 

DORA also doesn’t explicitly require the implementation of EDR or SIEM solutions.

500.15 Encryption of Nonpublic Information

Covered entities must have a written policy requiring encryption that meets industry standards for nonpublic information in transit over external networks and at rest. 

If a covered entity determines encrypting nonpublic information at rest is impractical, it may use alternative security measures that have been reviewed and approved in writing by the CISO. When exercising this option, the CISO must revalidate the infeasibility of encryption and the effectiveness of the compensating controls annually. 

DORA doesn’t require data encryption.

500.16 Incident Response and Business Continuity Management

Entities must have an Incident Response Plan designed to allow prompt response and recovery. Plan content must include: 

  • Goals of the plan 
  • Process for responding to incidents 
  • Roles and responsibilities and decision-making authority; 
  • Internal and external communications plan 
  • Identification of remediation requirements 
  • Documentation and reporting 
  • Backup recovery processes 
  • Root cause analysis 
  • Updating of incident response plans as necessary 

Entities must also have a Business Continuity and Disaster Recovery (BCDR) Plan designed to ensure the availability and functionality of systems and services in the event of a cybersecurity-related disruption. 

At a minimum, the BCDR plan must identify: 

  • Dependencies like documents, data, facilities, infrastructure, services, personnel, and competencies are essential to the continued operations of the covered entity’s business. 
  • Personnel responsible for implementing each aspect of the BCDR plan. 
  • Third parties necessary for the continued operations of the covered entity’s information systems. 

And include: 

  • A plan to communicate with essential persons in the event of a cybersecurity-related disruption to the covered entity’s operations, including employees, counterparties, regulatory authorities, third-party service providers, disaster recovery specialists, the senior governing body, and any other persons essential to the recovery of documentation and data and the resumption of operations. 
  • Procedures for the timely recovery of critical data and information systems and to resume operations as soon as reasonably possible following a cybersecurity-related disruption to normal business activities. 
  • Procedures for backing up or copying, with sufficient frequency, information essential to the covered entity’s operations and storing such information offsite. 

In addition to maintaining these plans, entities must: 

  • Ensure that current copies of the IR and BCDR plans are available to all employees during a cybersecurity event necessary for plan execution. 
  • Give training to all employees responsible for implementing the plans. 
  • Perform annual tests of IR and BCDR plans with all staff and management critical to the response and revise the plan as necessary. 
  • Perform annual tests of the ability to restore critical data and information systems from backups. 
  • Maintain backups necessary to restore material operations and ensure these backups are protected from unauthorized alterations or destruction. 

DORA covers the above NYDFS 500 requirements as follows:  

Incident Response Plan [Article 17(3(f))] 

  • Goals (not mentioned) 
  • Process (not specifically mentioned, but implied that this would be included in the IR Plan) 
  • Roles and responsibilities [Article 17(3(c))] 
  • Communications plan [Article 17(3(d))] 
  • Remediation requirements (not mentioned) 
  • Documentation and reporting (not mentioned) 
  • Backup recovery processes (not mentioned in the context of IR Planning) 
  • Root cause analysis [Article 17(2)] 
  • Updating of incident response plans [Article 13(3)] 

BCDR Plan [Article 11(2)] 

  • Essential dependencies [Article 11(5)] 
  • Personnel (not mentioned) 
  • Third parties (not mentioned) 
  • Communication plan (not mentioned) 
  • Recovery procedures [Article 12(1(b))] 
  • Backup procedures [Article 12(1(a))] 

Other requirements include: 

  • Copies of plans available during an incident (not mentioned) 
  • IR and BCDR Plan Training (not mentioned) 
  • Annual test of IR Plan (not mentioned) 
  • Annual test of BCDR Plan [Article 11(6(a))] 
  • Annual test of backup and recovery procedures [Article 12(2)] 
  • Maintain secure backups [Article 12(1) and Article 12(3)] 

500.17 Notices to Superintendent

NYDFS 500 includes the following requirements to submit notifications to the regulator: 

Notice of cybersecurity incident: 

  • Notify NYDFS within 72 hours of determining a cybersecurity incident at the covered entity, its affiliates, or a third-party service provider. 
  • Promptly respond to NYS DFS requests for information about the incident. 
  • Update NYDFS on any new information or material changes regarding the incident. 

Notice of compliance (signed by the CEO and CISO): 

  • Annual certification that the entity complied with the regulation during the prior calendar year or acknowledgment that the entity did not comply with the description of the gaps and timeline for remediation. 
  • Retain for NYDFS examination documentation supporting the certification or details of remediation plans for five years. 

Extortion payments (e.g., ransomware): 

  • Within 24 hours, notify NYDFS that an extortion payment was made. 
  • Within 30 days, explain reasons payment was necessary and diligence performed to find alternatives. 

Under DORA, financial entities must report major cybersecurity incidents [Article 19(1)]. Like NYDFS 500, this includes an initial notification followed by updates on changes and new information [Article 19(4)]. 

Time limits for the notifications are yet to be determined [Article 20(1(a)(ii))]. 

DORA doesn’t include requirements to certify compliance with the regulation or give justifications for making ransomware payments.

Get in touch for more help with the NYDFS 500

While NYDFS 500 reflects many of the exact security requirements as DORA, the New York regulation is more prescriptive in some areas. Understanding the differences is essential for financial institutions seeking to achieve compliance with both regulations. 

DORA generally takes a more principle-based approach, though this will likely change as the supporting Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) are published. 

WithSecure Consulting hopes the above comparison will help European financial institutions to more easily recognize the similarities and differences between NYDFS 500 and DORA and will be able to use this information to harmonize their efforts for assessing compliance with these regulations. 

Thank you for your interest. Please contact us with questions about this article or the NYDFS 500 and DORA regulations. Reversec is committed to supporting organizations in meeting regulatory and other cyber security challenges.

Related content

Our thinking

NYDFS 500 cybersecurity regulation: What’s changed?

August 31, 2023
NYDFS 500 cybersecurity regulation: What’s changed?
Whitepapers

NYDFS 500 – Plan for stronger cybersecurity compliance

July 1, 2024
NYDFS 500 – Plan for stronger cybersecurity compliance