Reversec’s four-month ISO 27001 journey
— and what you can learn from it

As a cybersecurity consultancy, we regularly support clients with ISO 27001 readiness and internal audits. So when we split from WithSecure and launched as an independent company in 2025, certification for this foundational security framework became a top priority. In this article, Lead Implementer Torbjörn Johansson and internal auditor Ondrej Doubek share their accounts of how a newly formed cybersecurity company achieved ISO 27001 certification in just four months — and why a sub-year timeline is achievable for others.

The significance of ISO 27001

ISO 27001 provides a structured, systematic and mature approach to managing security across the organization, from executive leadership to operational procedures. Certification for the standard is granted through an audit by an independent third party.

Across Europe and in most regions outside the United States, it is the most widely adopted security standard. While demanding, it offers clear guidance and a well-defined structure that makes implementation manageable. Achieving ISO certification demonstrates that an organization has the right controls in place and treats security as a serious, ongoing responsibility.

Motivation

From the beginning, ISO certification was a clear requirement for Reversec. Prior to launching our company, we operated under WithSecure, where the standard was already in place. Once we became independent, clients expected us to maintain the same level of maturity, posture and evidence-based security practices.

Our decision was also shaped by ISO 27001’s strong position in Europe and its recognition as a credible way to demonstrate alignment with several EU regulations, including the increasingly relevant NIS2 Directive.

Timeline: Kickoff to certification

The preparations typically begin by defining the scope of what you want certified. Our project started in early February 2025, with the goal of achieving certification quickly to minimize the transition gap between WithSecure Consulting and Reversec. This helped reassure customers that continuity would be maintained.

Torbjörn Johansson led the implementation of our Information Security Management System (ISMS) while also serving as CISO, a role he continues to hold today. His background in information security and experience running ISO 27001 projects for clients gave us a solid foundation to build on.

‘To keep the process on track, management made it clear that ISO 27001 certification was a mandatory initiative. At the start of the project, Executive Vice President Scott Reininga, who was expected to become CEO, sent a message to the entire organization: “We’re doing this. Make yourself available and be prepared to contribute.” That message set the tone.

For internal follow-up, Torbjörn provided weekly updates to the project’s steering group. At the same time, members of the group were also managing Reversec’s broader transition, rolling out ERP, CRM, HR and finance systems. Despite the parallel efforts, Torbjörn consistently received the support he needed.

ISO 27001 timeline

Stage 1 – Documentation review

Within two months, we were ready for Stage 1 of the initial audit, which took place on 12 April. This stage involves a review of required documentation by the external auditor to confirm that the minimum documentation exists and aligns with the company’s scope and ambitions. Our external auditor was DNV, a leading assurance and risk management firm.

In late April, we brought in Ondrej Doubek, a certified ISO 27001 Implementer and Auditor, to conduct the internal audit. His role was to assess the ISMS for any gaps or deficiencies. To maintain independence, Ondrej had not been involved in creating the ISMS.

Following Ondrej’s two-week assessment, the team began preparing for the next stage of the external audit. Identified issues were addressed over the course of about ten days, leading up to the next stage of the initial audit.

Stage 2 – Certification audit

The certification audit was focused on how well Reversec’s processes and procedures were functioning. External auditors examined our organization and evaluated how we had adopted the ISMS. This stage included extensive interviews across the company and took place over four days, from 16 to 19 June.

The auditors looked for major nonconformities that could delay certification. Reversec had no major nonconformities and one minor (for which we successfully submitted a corrective plan). The auditors also highlighted three opportunities for improvement — suggestions, not misses — which we’ll incorporate into our continuous improvement cycle. This outcome allowed the auditors to proceed with issuing the certification.

Finally, DNV conducted a third-party review of the findings. With no further concerns, the certificate was approved and issued in July.

Scope and audit sizing

Reversec had around 250 employees and three offices in scope. The audit covered our Swedish headquarters, along with sites in Manchester and Singapore. The Singapore office was audited remotely through a video walkthrough.

The total effort for the project amounted to approximately 100 FTE days. This excludes work already underway as part of the broader transition, where additional instructions were provided by the project team to align with relevant requirements.

Typical durations

  • Three to four months is exceptionally fast for the certification. It requires full commitment, coordination, cybersecurity expertise and a clear understanding of the process from everyone involved.
  • Six months is a realistic minimum for organizations with a highly engaged team.
  • Twelve months is a typical timeline for companies starting from scratch or without prior certification.

Roles and responsibilities

The implementation involved staff from Finland, Denmark, Stockholm, Singapore, Manchester and London. Everyone with a stake in security from executive leadership to administrative staff in Finance contributed to the project.

  • Torbjörn Johansson served as the lead implementer of the ISMS.
  • Ondrej Doubek conducted the internal audit.
  • The project’s steering group included the operations and transition manager, Nordic consulting manager, and frequently the EVP.
  • Our Senior Engagement Manager in the UK supported the project by allocating available capacity and bringing in team members who weren’t assigned to client work.
  • The Singapore office manager facilitated the video for that location.

Inside the internal audit

During his two-week document review, Ondrej Doubek examined and compiled all relevant materials into a structured report, closely following the ISO standard — familiar territory from his work with clients. To maintain objectivity, Ondrej remained at a distance throughout the project until the review phase. “Whenever I thought I could help with writing something, I was told, ‘No, you stay away,’” Ondrej reflects on the process.

The purpose of the internal audit is never to nitpick. It should aim to exceed the thoroughness of the external audit, helping the company prepare for the external audit in a meaningful way. As a cybersecurity company that supports clients with ISO compliance and internal audits, our assessment had to reflect our high ambitions and go well beyond the standard’s minimum requirements.

The process was complicated by the fact that the ISMS was still evolving. Before Ondrej could submit his report, a policy might have changed twice, requiring him to revise his findings. He was effectively auditing a moving target.

Despite these added challenges, the auditor was highly satisfied with the outcome, describing the internal audit as exceptionally thorough and uncompromising.

“Whenever I thought I could help with writing something, I was told, ‘No, you stay away.’”

Why four months was possible

In most organizations, policy creation involves multiple rounds of HR approval. Staff often need time to familiarize themselves with ISO 27001, which slows progress.

Reversec was already fully tuned to the standard. Our staff understood the importance of the certification, trusted the policies, and didn’t need convincing. We also had a large pool of experienced contributors.

Commitment from top management played a central role in our ISO compliance journey. Leadership prioritized certification and allocated the resources to make it happen. When projects lose momentum, it’s often because management isn’t fully engaged.

Given the nature of our business, we had in-house cybersecurity expertise and extensive experience with ISMS implementation. This allowed us to access and adapt a wide range of templates and documentation for internal use. Adjusting policies and procedures from WithSecure’s certified ISMS to suit our needs saved significant time.

We offer this advantage to our clients as well. While no two ISMS’s are identical, we can noticeably accelerate the implementation process by drawing from our extensive library of curated structure templates and example documents.

What we’d do differently

Looking back, we began our certification journey earlier than ideal, while Reversec was still being established as an independent consultancy. At that point, we were still defining our business processes, building our IT environment and setting up core governance. Not a setup we’d recommend to other companies, but it was unavoidable given the circumstances.

“Implementing ISO 27001 while building the company was challenging, but it also had advantages.”

For most organizations, a stronger starting point is when:

  • The company structure, key processes and stable IT environments are in place.
  • Leadership roles and responsibilities are well defined.
  • There is a clear understanding of critical services, data flows, and applications that require protection.
  • Internal expectations, customer commitments and legal or regulatory obligations are clearly understood.
  • Security awareness and basic controls are already in place.
  • Risk management practices are at least partially established.

This foundation allows the ISO 27001 project to focus on improving and formalizing what already exists, rather than designing everything from scratch.

“Implementing ISO 27001 while building the company was challenging, but it also had advantages,” Torbjörn Johansson recalls. “It meant we could embed security and compliance principles directly into the way we operate — not bolt them on later.”

Recommendations for ISO 27001 success

  • Begin with a gap analysis.
    Compare your current state with certification requirements before committing.
  • Secure management involvement.
    Leadership must provide clear direction and maintain momentum.
  • Design the ISMS to support real security.
    Avoid measures that look good on paper but fail in practice.
  • Ensure competence in information security.
    Expertise is essential for risk-based decisions a posture that reflects current threats.
  • Define a clear scope early.
    Outline what is included and what will be certified. This is key to planning resources and costs.
  • Focus on risk, not just controls.
    ISO 27001 is risk-based. Manage and assess risks properly. Management should understand the risks and how they’re addessed.
  • Leverage existing resources.
    Use available tooling, documentation and processes. Teams and SharePoint can support the effort.
  • Keep documentation practical.
    Write policies for people to follow, not just for audits. Avoid overcomplication.
  • Run awareness and training early.
    Staff should understand objectives, what’s being measured and why it matters.
  • Manage the project efficiently.
    Don’t underestimate time and resources.
  • Use available capacity flexibly.
    Reassign tasks when necessary to maintain progress.
  • Maintain focus without burnout.
    Set clear milestones to facilitate hard work. Avoid pushing at an unsustainable pace.
Ondrej Doubek
Reversec can support organizations through every step of the ISO 27001 certification journey.

After certification

The ISMS is called a management system for a reason: Once implemented, it needs to be maintained. Regular activities are expected throughout the year between audits. The standard also calls for continuous improvement, which means the organization must evolve to stay compliant.

Why certification matters

One of the biggest advantages of ISO 27001 certification is client trust. Being able to show that an independent auditor has verified your security posture carries weight.

Certification also helps avoid missed opportunities. Without it, you may not qualify to pitch for certain types of business. This is especially true in the public sector.

Another benefit is regulatory alignment. Across regions and industries, organizations face different regulations but share a growing need to demonstrate compliance. With ISO 27001 in place, you’re well positioned to align with other frameworks and future requirements. For example, the entire ICT risk component of DORA and NIS2 is covered by the ISO standard.

How we can help

We support organizations through every step of the ISO 27001 certification journey — from initial gap analysis to successful certification and ongoing compliance.

Our services include:

  • Gap analysis & readiness review – Understand where you stand today and what’s needed to meet ISO 27001 requirements.
  • Implementation support – Develop policies, procedures, and controls aligned with ISO 27001:2022.
  • Internal audits – Independent audits to verify effectiveness and readiness before certification.
  • ISMS management – Ongoing support to maintain compliance, either through a virtual CISO or as operational assistance to your in-house CISO.

Whether you’re starting from scratch or strengthening an existing ISMS, we can tailor our involvement to your needs.

Related content

Whitepapers

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

March 28, 2025
Connecting the dots: Shared requirements of ISO 27001, NIS2, DORA, and NYDFS
Webinars

Shared requirements of ISO 27001, NIS2, DORA, and NYDFS

September 16, 2025
Shared requirements of ISO 27001, NIS2, DORA, and NYDFS
Our thinking

A practical guide to PCI DSS compliance

August 18, 2025
A practical guide to PCI DSS compliance

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

What do security standards and regulations like ISO 27001, NIS2, DORA and NYDFS have in common? A lot actually. We’ve mapped out the shared requirements for you.

The cybersecurity landscape is flooded with regulations as governments worldwide respond to complex and frequent cyber threats, data breaches, and national security worries. CISOs across various sectors must now navigate a web of compliance requirements that vary by region and industry. However, the core requirements of security standards and regulations like ISO 27001, NIS2, DORA and NYDFS are often very similar. 

“The big secret about regulations and security standards is that they are all essentially the same.”

Four of our top global security and risk management experts have taken the ISO 27001 standard and mapped it against these key regulations:

  • The Network and Information Security Directive 2 (NIS2)
    • Raises the baseline across critical sectors in Europe and moves organizations toward prevention, accountability, and context‑driven risk reduction.
  • The Digital Operational Resilience Act (DORA
    • Sets a single, principle-based standard for operational resilience in the EU financial sector. Applies across twenty financial entity types and introduces EU‑level oversight for critical third‑party providers.
  • The NYDFS Cybersecurity Regulation (23 NYCRR Part 500)
    • Sets prescriptive expectations for financial institutions in New York, including board cybersecurity expertise, mandatory social‑engineering exercises, tabletop drills, and crisis management testing.

The result is a practical whitepaper outlining their common security policies, controls, and activities to help you kick-start your security risk management journey.

Download the whitepaper to discover

  • What each of these regulations means in practice 
  • Where and to whom they apply
  • What these regulations have in common, and 
  • What you can start doing right now to become compliant with all of them 
WHITEPAPER

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

Download

Related content

Our thinking

Insights into the NIS2 Directive

June 1, 2024
Insights into the NIS2 Directive
Our thinking

NYDFS 500 vs. DORA: Comparison for European financial institutions

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

Cracking the NIS2 Code: Compliance Solutions and Practical Advice

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

Top 5 common
misconfigurations in
cloud environments

Many organizations believe that once their cloud environment is configured, their job is done. But this “set it and forget it” mentality can lead to major security vulnerabilities. Cloud environments are dynamic and require regular updates and reviews – to adapt to new threats and changes. Not staying on top of your cloud configurations can leave you with outdated security measures and put you at increased risk.

Another common misconception is that an initial entry point breach isn’t likely to happen to you. Organizations often set up security controls to restrict user logins and limit access to development environments. This in turn results in these controls being often treated as a complete security boundary that cannot be crossed. However, that is not entirely true. Attackers are becoming increasingly sophisticated, which is why it’s crucial to operate under the assumption that a breach can, and eventually will, happen to you. This mindset will help you evaluate the potential impact of a breach and implement measures to minimize damage.  

Ready to see what we typically encounter in our engagements? Let’s dive in! 

It’s crucial to operate under the assumption that a breach can, and eventually will, happen to you.

#1 Excessive privileges

One of the most common problems in cloud environments is the granting of excessive privileges to users and machine accounts. This misconfiguration can lead to privilege escalation, where a malicious actor gains higher-level access than intended. Cloud providers offer thousands of granular permissions, making it hard for administrators to fully understand the potential impact of each one.

For example, an application might only need permissions to read and write in a specific storage bucket or database resource but it might be granted additional, unnecessary permissions, increasing the risk if the account is compromised. The solution involves carefully reviewing and limiting permissions to the minimum level necessary for each role. This process can be time-consuming, especially for larger organizations, but it’s key to maintaining security. 

Here are some practical ways to limit excessive privileges

  1. Segregation of organizational workloads:
    Where possible, different applications and the resources required by them should be provisioned into their own granular unit (AWS account, Azure subscription or GCP project, etc.). This would provide a strong control to minimize the impact of excessive permissions and limit the impact of a compromised identity.

  2. Review current permissions:
    Regularly audit the permissions granted to users and machine accounts. Identify and remove any unnecessary privileges.

  3. Implement role-based access control (RBAC):
    Use RBAC to assign group permissions based on roles within an environment and the level of access appropriate to that workload. This helps ensure that users only have access to what they need.

  4. Use temporary credentials:
    Where possible, use temporary credentials that expire after a certain period. This reduces the risk of long-term exposure.

  5. Automate where possible:
    Utilize automation tools to help manage and review permissions. While some manual review is always necessary, automation can significantly reduce your workload.

#2 Poor secrets management

Another common misconfiguration that impacts organizations of all sizes is poor secrets management. This issue often leads to privileged escalation opportunities within a cloud environment. With the widespread adoption of cloud infrastructure, ClickOps is just no longer practical, especially for organizations running multiple projects. As a result, many companies have turned to infrastructure as code (or IaC) to manage their cloud environments. 

IaC allows you to define your company’s cloud infrastructure using templates in a human-readable code format. These templates define how your cloud environment should look and how individual resources should be configured. But while this approach does simplify the management of large estates, it can also introduce poor development practices, such as storing credentials or secrets in plain text within these templates. 

The risks of poor secrets management

Storing secrets in plain text is a major security risk. Any user with access to these files can potentially use the exposed credentials to perform unauthorized actions on resources they typically wouldn’t have access to. For example, if a storage bucket’s credentials are stored in plain text, an attacker could gain access to sensitive data stored in that bucket. Similarly, hard-coded credentials could allow unauthorized access to other applications or services, leading to data breaches or other security incidents.

Follow these steps to improve secrets management

  1. Use secure key storage:
    Store secrets in secure key management services or vaults. These services provide a secure way to manage and access secrets without exposing them in plain text.

  2. Reference secrets securely:
    Instead of hard-coding secrets into templates, reference them from secure storage. This way, the actual secrets are fetched dynamically during execution, reducing the risk of exposure.

  3. Regular audits:
    Conduct regular audits of your IaC templates and other deployment scripts to ensure no secrets are stored in plain text. Automated tools can help you identify and remediate these issues.

  4. Educate developers:
    Make sure your developers understand the importance of secure secrets management and follow best practices when writing IaC templates. 

#3 Long-lived credentials

Closely related to poor secrets management is the issue of long-lived credentials. While not inherently a vulnerability, long-lived credentials can pose significant security risks if not managed properly. These credentials, which have long expiry windows, can be exposed in various ways, such as being accidentally committed to public code repositories, left unprotected in deployment templates or more generally insecurely handled by human users. 

Take these practical steps to mitigate the risks of long-lived credentials

  1. Avoid storing credentials in plain text:
    As with secrets, avoid storing long-lived credentials in plain text. Use secure storage solutions instead.
  1. Use short-term credentials:
    Where possible, use short-term credentials that expire after a short period. For example, AWS recommends using temporary credentials gained from a federated identity provider instead of using long-lived IAM user credentials.
  1. Regularly rotate credentials:
    Implement a policy to regularly rotate machine credentials to minimize the risk of exposure.
  1. Monitor and audit:
    Continuously monitor and audit the use of credentials to detect any unauthorized access or anomalies.

#4 Exposure of public endpoints

Cloud providers design their services to be user-friendly and easily manageable, often more so than traditional on-premise infrastructure. But this convenience comes with its own set of risks. One of the biggest is that resources in the cloud often have public endpoints, making them accessible from anywhere in the world

The risks of public endpoints

Public endpoints let users interact with cloud resources directly via the Internet. While this is convenient for management purposes, it also means that if an attacker gains access to your environment, they can do whatever they want from wherever they may be. For example, if an attacker compromises your account, they could log in from another country and make changes to your resources without any geographical restrictions. 

This issue is particularly prevalent in Azure, where public endpoints are often the default configuration for many resources. However, many organizations don’t need these endpoints to be public and would benefit greatly from restricting access.

Here are some simple tips on how to manage public endpoints

  1. Restrict access with IP Allow Lists:
    Configure endpoints to only be accessible from specific IP addresses. That way you can control who can access your resources based on their IP location.
  1. Use private endpoints:
    Where possible, make endpoints private so that they are only accessible from within your cloud environment. This adds an additional layer of security by limiting external access.
  1. Regular audits:
    Conduct regular audits of your cloud environment to identify and secure any public endpoints that don’t need to be exposed.
  1. Assume compromise:
    Work under the assumption that your environment could be compromised. By restricting public endpoints, you’ll limit the potential damage an attacker can do if they gain access.

    Here’s an example
    Imagine a storage bucket that contains sensitive data. If this bucket has a public endpoint, anyone with the right credentials can access it from anywhere. By restricting access to specific IP addresses or making the endpoint private, you’ll ensure that only authorized users within your network can interact with that data. This will greatly reduce the risk of unauthorized access and data breaches. 

#5 Overly exposed internal networking

The last cloud misconfiguration on our list is overly exposed internal networking. This issue has been around for years, even in traditional on-premise networks. Organizations do often focus heavily on protecting their environments from external threats with robust perimeter defenses. But once an attacker gains a foothold inside your network, most of those internal protections aren’t enough to keep you safe

The risks of overly exposed internal networking

In many cloud environments, internal network segmentation isn’t implemented to the level that it should be. Engineers might allow certain IP ranges to communicate freely for testing purposes, or resources might be deployed in a flat network structure. This lack of internal segmentation means that if an attacker compromises one resource, they can potentially move laterally within the network, accessing other resources that should be isolated. 

For example, if an attacker compromises a virtual machine (VM) in the cloud, they could use it as a stepping stone to reach other sensitive applications or data. Without proper internal network segmentation, an attacker can move freely, increasing the risk of a significant breach.

Follow these steps to improve your internal network segmentation

  1. Implement network segmentation:
    Divide your cloud environment into smaller, isolated segments. Make sure that only necessary communication is allowed between these segments.
  1. Use security groups and network ACLs:
    Use security groups and network access control lists (ACLs) to define and enforce network traffic rules. This will help you restrict unnecessary communication between resources.
  1. Regularly review and update your network policies:
    Conduct regular reviews of your network policies to make sure that they are up-to-date and reflect the current needs of your environment. Remove any unnecessary permissions or access.
  1. Keep an assume breach mindset:
    Work under the assumption that a breach is possible. Evaluate the potential impact of a compromised resource and implement controls to minimize the blast radius.

    Here’s an example
    Consider an application that only needs to communicate with a database and a few other services. By segmenting the network and restricting the application’s communication to only these necessary services, you’ll be reducing the risk of lateral movement by an attacker. If the application is compromised, the attacker would have limited access and would be unable to reach other resources.

You don’t have to do it alone – Reversec can help

As the digital landscape evolves, avoiding these top 5 misconfigurations in the cloud will help your organization stay safe in an increasingly complicated and threat-laden world.

Here’s how we can help.

Assumed breach assessments
Think it can’t happen to you? Think again. We help organizations conduct assumed breach assessments by simulating attacks as specific user personas within your company. It’s a strategic service designed to identify potential actions from that user’s perspective and addresses vulnerabilities. It helps you identify issues and resolve them comprehensively – before a real breach happens.  

Collaborative exercises
Staying on top of security – together. Collaborative exercises with a security consultancy like Reversec are invaluable to keeping your organization and sensitive data safe. These exercises offer fresh perspectives, helping you to identify and fix any misconfiguration issues you may have. Initial assumptions made during the setup of a cloud environment may no longer be relevant as services and features change. Regular reviews and updates are key to maintaining a secure environment.

The value of fresh perspectives
Having a fresh pair of eyes review your cloud environment can reveal things your team may have missed. Our security consultants can help you understand why certain configurations were set up in the first place and, when needed, propose more secure alternatives. Together, we’ll ensure that your environment is always secure and up-to-date with the latest best practices.

Challenging assumptions
Cloud environments are complex, and it’s crucial to question assumptions about service operations. Organizations should continuously review and understand the exact risks posed by their cloud configurations. Through our research-driven approach, we help companies in identifying the gap between what cloud providers claim is possible and what is practically achievable – essentially, the difference between theoretical and practical functionality. 

Misconfigurations in cloud environments often occur due to misunderstood nuances to how cloud resources operate in any provider and due to a lack of regular holistic auditing of the deployed resources.

By assuming that breaches are possible, evaluating user access, conducting assumed breach assessments, and collaborating with security experts, you can significantly enhance your organization’s cloud security posture. This proactive approach will not only secure your environment but also make it more resilient against potential attacks.

If you would like to hear more about how we can help you protect your cloud environment, don’t hesitate to contact us!

Our Cloud Security experts are happy to help.

Related content

Our thinking

How to run successful Kubernetes attack simulations?

February 21, 2025
How to run successful Kubernetes attack simulations?

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: 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

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

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