For businesses already aligned with robust frameworks like ISO 27001, compliance with these new regulations will require only incremental changes to existing controls. In most cases, the focus will be on areas such as incident reporting and ensuring processes meet the specific requirements outlined in DORA and NIS2. Let’s break this down.

What Are DORA and NIS2?

DORA:

DORA aims to ensure the operational resilience of financial institutions by requiring them to prepare for, withstand, recover from, and adapt to disruptions. While its primary focus is on financial entities such as banks, investment firms, and payment providers, it also applies to their critical third-party providers, such as:

• IT service providers offering cloud computing, data storage, or disaster recovery solutions.
• Managed Service Providers (MSPs) delivering IT or cybersecurity support to financial institutions.
• Outsourced service providers providing software, analytics, or operational support.

If you support the financial sector with technology or operational services, DORA’s requirements likely extend to your organisation.

NIS2:

NIS2 expands on the original NIS Directive, introducing stricter cybersecurity requirements for a broader range of industries providing critical or essential services. The affected organizations fall into two main categories:

1. Essential Entities:
   • Energy providers, such as electricity, oil, and gas suppliers.
   • Transportation and logistics companies.
   • Public healthcare services, including hospitals and clinics.
   • Digital infrastructure providers, such as data centers and DNS providers.
2. Important Entities:
   • IT service providers, including MSPs and cybersecurity firms.
   • Manufacturers critical to supply chains.
   • Providers of food and water supply systems.
   • Postal and courier services.

Even if you’re outside the EU, your compliance might still be necessary if you provide services to EU-based businesses.

Why ISO 27001 Provides a Strong Foundation

ISO 27001, the internationally recognised standard for information security management, provides the fundamental building blocks for compliance. It ensures:

1. Risk-based thinking: Organisations identify and address risks relevant to their business and industry.
2. Established processes: Controls for access management, incident response, and vendor oversight are already in place.
3. Continuous improvement: A cycle of regular reviews ensures security evolves as threats do.

If your business is ISO 27001 certified, much of the heavy lifting for DORA and NIS2 compliance is already done. The key will be reviewing your existing controls and making necessary adjustments to align with specific regulatory requirements, such as:

• Enhancing incident response times and reporting procedures.
• Documenting third-party risk assessments more comprehensively.
• Testing operational resilience through more frequent simulations.

A Simple Process for DORA and NIS2 Compliance

To streamline your compliance efforts, we recommend the following steps:

1. Understand the Requirements: Review the text of DORA and NIS2 to understand how they apply to your business. Focus on operational resilience, incident reporting, and supply chain security.
2. Gap Assessment: Conduct a gap analysis against your existing frameworks and controls. Identify where your current controls meet the requirements and where enhancements are needed.
3. Update Policies and Procedures: Tweak your incident management, third-party risk, and operational resilience plans to align with the regulations. Ensure documentation is thorough and up to date.
4. Test Your Controls: Conduct tabletop exercises, simulate incidents, and test your business continuity and disaster recovery plans to ensure operational resilience.
5. Train Your Teams: Educate your staff about the new requirements, focusing on the importance of timely incident reporting and robust cyber resilience.

Compliance Without the Stress

The key message is this: compliance with DORA and NIS2 should not feel like starting from scratch. If your organisation has invested in frameworks like ISO 27001, or similar, you’re likely already well on your way to meeting these new standards. The focus should be on fine-tuning your existing processes rather than overhauling them entirely.

At Calligo, we specialise in helping businesses navigate complex regulatory landscapes, including DORA and NIS2. Whether you need a gap assessment, guidance on updating your controls, or help training your teams, our experts are here to support you.

Ready to simplify your compliance journey? Contact us today to learn how we can help you turn regulatory challenges into opportunities for strengthening your cybersecurity and operational resilience.

The post Demystifying EU Regulations: DORA and NIS2 – What They Mean for Your Business appeared first on Calligo.

Introduction 

Behind every impactful dashboard you’ve ever seen is a well put together plan and an understanding of the objective in creating the tool. It does not matter if the dashboard is being used in a business context or to tell an interesting data story – any successful dashboard requires meticulous planning and an understanding of the underlying data paired with foundational data literacy skills. Regardless of what you’re building and who it is being built for, effective requirements gathering will generally lead to greater efficiency in development and greater user satisfaction. 

Requirements gathering is not a novel concept, but it’s not common either. Individuals and organizations often forgo the process under the misconception that they’re saving time. The reality is that not investing this time upfront leads to inefficiencies down the road, and those inefficiencies can be multitudes greater than the time it would have taken to effectively gather requirements prior to starting development. Multiple rounds of feedback, unsatisfied end users, and dashboards that receive little to no usage after going live are, unfortunately, staples of the analytics world today.  

The good news is that it doesn’t have to be this way. With an understanding of how to gather requirements plus the knowledge of why it is such a crucial step, you’ll be able to gain buy-in from stakeholders and deliver excellent, meaningful analytics products to end users.  

What is Requirements Gathering? 

When aiming to understand what requirements gathering is, it’s important to start by understanding what it is not. There are numerous strategies that attempt to mimic the process of gathering requirements, so let’s address a few of the most common: 

• A single ticket submitted to an IT/analytics team – teams that service multiple parts of the organization often set up a ticketing system to elicit requirements and requests from end users. The problem is that teams often begin development immediately after receiving a ticket that often has limited information. The result is many hours or days that have been sunk into the development of a tool that is built on assumptions and has little chance of exciting users, or even meeting their needs, when it’s released. This is not an indictment of ticketing systems – in fact, ticketing systems are a great way to organize workstreams and manage a high volume of stakeholders, but it’s essential to move into a structured requirements gathering exercise as the first step after receiving a request. 

• Technical requirements without business context – requirements gathering is meant to be a thorough, holistic approach to understanding what is being built and why. A common trap that developers fall into is believing that they only need to elicit the technical aspects of what they’re building. They see themselves as strictly technical resources, their stakeholders as strictly business-focused contributors, and they don’t bridge the gap between the two parties. A collaborative approach with buy-in from both sides to solve the business problem is key in requirements gathering. Empathy, curiosity, and an ability to step outside of the technical development world are essential skills to practice. 

• Defining requirements for others – it should be stated that imagining what others need and developing products for them based on those gut feelings is not an effective way to work with end users. 

So, we know what does not constitute effective requirements gathering, but the real question is: how do we ensure that we go through this process and come out with the necessary information? Requirements gathering can be messy; it can and should result in jumbles of notes, ink smeared whiteboards, and a feeling of renewed energy for the design and development phase of the project. A lot of information will come up during these 1–2-hour sessions, but the following 4 focus areas will help structure your time: 

• Determine the objective – drill into the “why” behind what is being built. It’s perfectly acceptable to start a requirements gathering session by asking the question, “why are we building this?” The idea is to drill into the business problem that we’re hoping to solve, and to understand how we plan to solve that. Ideally, we can create an objective statement that is measurable, then work backwards to understand how a specific tool or technology will accomplish that goal. 

• Define the audience – aside from the overall objective, the most important consideration is the audience. Understanding who will use the tool, how and when they will use it, and their general ability to use analytics products are essential pieces of knowledge when considering design and deployment. The end goal is the ability to create specific user stories that can be used to guide the design and development of the tool in order to drive the greatest adoption. 

• Outline priority questions – this is the time to dive into specific metrics and dimensions related to the data that will be utilized for the project. This information will be used to guide the design of individual visualizations and it is likely that you’ll map specific questions to specific visuals as you move into the design phase. Questions such as “How do each of my sales regions and the salespeople within them rank amongst one another by total volume sold?” represent the level of detail desired when drilling into priority questions. 

• Document dashboard features/other details – lastly, we want to document any special functionality requests. Often times, users will be expecting certain features that they have seen from other tools, or that they have been imagining as valuable for the tool you are building. Think about filters, sorting, data exports, printer-friendly concepts for those paper lovers. These items can be make or break for users; spend time identifying those needs so you can plan to integrate them into the product. 

Final Thoughts 

Remember that requirements gathering is inherently social and requires a deep level of curiosity. It should be collaborative – stakeholders need to be involved and to feel that they’re involved. This isn’t just about soliciting requirements – it’s about gaining buy-in from end users and having them know that they played a crucial role in developing the end product. By defining the objective, audience, priority questions, and key functionality in collaboration with your stakeholders, you will be well equipped to move into the design phase of your project.  

Lastly, it is important to understand when requirements gathering has concluded. In an effort to provide clarity around when we have reached that point, formal documentation is passed to stakeholders and their sign-off is requested. By seeing the requirements formalized and delivered, you and your stakeholders will know that milestone has been completed, and that content will now be used to guide the design of the product. See below for a template that you can use next time you engage in requirements gathering.

REQUIREMENTS DOCUMENT TEMPLATE 

<Dashboard Name> 

<Date> 

PROBLEM STATEMENT 

<What are the client’s pain points? Why do they need this dashboard? Why have they come to us?> 

OBJECTIVE OF DASHBOARD 

<What is the business value of the dashboard? Does it help improve revenue? Does it highlight costs that can be reduced? Does it tell the story of an organization’s efforts? Does it increase employee retention?> 

AUDIENCE & USAGE 

<Description of section> 

• Who will use the new dashboard 

• Outline permissions 

• When it will be used 

• How often it will be updated 

• Any subscriptions should be mentioned here 

• Security features 

• How it will be distributed & shared 

BUSINESS QUESTIONS & ACTIONS 

<Description of section> 

DASHBOARD SPECIFICS 

• Date range of the data 

• Filters 

• Etc. 

QUESTIONS 

• List any outstanding questions here 

The post Requirements Gathering for Analytics Projects appeared first on Calligo.

The last few years have been filled with the promise of efficiency gains from data science models, but relatively few companies have actually achieved success in capitalizing from model deployment. There are many reasons that this may be the case, including difficulty in framing the correct problem, lack of good data, or failure to plan an adoption strategy. We can help with that. However, a good data science team working with a good data science platform may be able to overcome these difficulties and still fail to deliver a model that delivers positive returns. One likely but not well-understood reason is that if the model objective is not aligned with the business objective, even seeming excellent model results do not translate into business success. The focus is on error and not success.

The solution to this problem requires thinking about ROI as a science rather than as a dream. While data science applies the scientific method to ensure that truth emerges from data, ROI-Science takes a similar approach, applying the scientific method to the combination of business data plus business process with the direct goal of optimizing ROI. This approach deviates from standard data science since it requires directly including ROI in a model as an objective. The ROI-first approach is designed to think about return at the same time as data. Consider the following data science question from a traditional approach and from an ROI-first approach:

Traditional:

Question: What machine parts are most likely to fail?

Objective: Predict probability of failure

ROI-first:

Question: How can I choose the correct replacement so that my total repair cost is minimized?

Objective: Minimize the total predicted repair costs of part replacement.

These approaches are really the same question from the data side, but differ in that the second question incorporates the repair process as an objective, and the machine learning model can actually be designed so that it learns how to minimize repair costs. In ROI-Science, the objective is an explicit mathematical construct rather than an abstraction. Not only will the model perform better in terms of your business goals, but the model output also tells you exactly what your expected return is, a great improvement over standard data science approaches. The second question formulation directly leads to the proper business action.

This ROI-first approach requires a great deal of precision and expertise for proper implementation to properly embed business processes into a machine learning objective function. To try to understand how objective functions work and the potential difficulties of an ROI-first approach, let’s first consider at a high level the mathematics behind logistic regression since it is an acceptable analog that demonstrates how these ideas can be implemented. Without equations, we can say that logistic regression solves the following:

What is the set of coefficients such that the likelihood of the input data is a linear combination of the inputs?

In a thorough derivation, we would write down the likelihood function as a linear combination, and solve for the gradient of the likelihood function equal to zero, as in any standard optimization procedure. For logistic regression, the assumptions on optimization give rise to the sigmoid or logit function. The coefficients are then determined by iterating through a gradient ascent algorithm using Newton’s method. Ultimately, the inverse logit of probabilities are given as a linear combination of inputs as determined by the coefficients.

The key point is this: Optimizing relative to an objective requires finding coefficients that satisfy a zero-gradient condition.

Machine learning algorithms operate in much the same way, with an objective function, analogous to the logit function, used along with an iterative procedure that calculates optimal coefficients. There are certain nice properties of the likelihood and logit function that make logistic regression appealing, including that it is scale and rotation invariant, which reduces the work of the data scientist in preparing data. Additionally, it is very nice that the algorithms always converges and the optimization procedure always finds coefficients that are associated with a global maximum of the likelihood function. However, logistic regression, linear regression, and most machine learning algorithms have the drawback of being very sensitive to multicollinearity, or highly correlated inputs. The reason for the problem is that the Hessian second-derivative matrix of the input function becomes ill conditioned and non-invertible. No matter what technique is used, multi-collinearity cannot be avoided.

In the ROI-first approach, let’s ask the question not of whether the log-likelihood of probabilities is optimized, but whether a more general business profit function is optimized. If a suitable function is found, machine learning algorithms can be developed that directly lead to profit rather than to some esoteric function with little business relevance. Learning from logistic regression, we can look at some of the similar properties that must be avoided.

Multicollinearity will still lead to a nonsingular Hessian resulting in potentially large and incorrect coefficients.

2. Additionally, an objective function cannot collapse data to create multicollinearity.

3. For some problems, scale invariance, rotation invariance, or translation invariance may be required, and the function must be either designed to be invariant or the scale must be applied to results.

4. For the logit function, optimization ensured a global maximum of the likelihood, but in general, we would not expect that to be true, and it is possible that local maxima cause a poor set of coefficients to be found. To ensure global maxima, the objective function must be convex.

In summary, far more powerful models can be built by considering business optimization during model training and building the appropriate objective functions so that business optimization drives model optimization. Designing the right functions with the right structure can ensure that you get the greatest ROI from your machine learning solution.

Read more about how we can help with your machine learning needs here

The post A different reason data science models fail and an ROI-first approach appeared first on Calligo.

London, 18 December 2023 — Calligo, a global leader in data transformation, is thrilled to announce a groundbreaking partnership with NourNet, the foremost digital transformation enabler in the Kingdom of Saudi Arabia. With offices in the US, Canada, UK, Channel Islands and Ireland, Calligo’s extensive experience in providing end-to-end data solutions, from cloud services to cutting-edge machine learning, positions the company as a catalyst for AI innovation in Saudi Arabia.

This collaboration aligns seamlessly with Calligo’s strategic vision to explore important new markets, with Saudi Arabia emerging as a key player in the realm of machine learning and AI, driven by the Kingdom’s ambitious Vision 2030 artificial intelligence goals.

As part of this partnership, NourNet is gaining exclusive access to Calligo’s state-of-the-art machine learning platform, ALPHI. This empowers NourNet to provide cutting-edge AI solutions to local corporate clients, meeting the increasing demand for advanced technologies in the Saudi market.

NourNet’s CEO, Mr. Amjad A. Hafez stated “Since the beginning, we have always catered to our clients’ specific requirements by offering comprehensive and individualized services. As a result of this agreement, NourNet will be able to expand its digital services even further, and it will be able to reaffirm its commitment to offering localized services that are in line with its clients’ goals of improved operations and cost savings through emerging technologies”.

This collaboration with NourNet is part of Calligo’s broader strategic initiative to expand its footprint in the Middle East, focusing on fast-growing markets hungry for AI and advanced analytics.

Expressing his enthusiasm about the partnership, Paul Comerford, Calligo’s CEO, stated, “We are delighted to collaborate with NourNet and contribute to the digital transformation journey in Saudi Arabia. This partnership not only aligns with our strategy to explore new markets for our advanced analytics and AI solutions but also presents an exciting opportunity to work closely with our friends at NourNet.”

Calligo and NourNet are committed to driving innovation, pushing the boundaries of what is possible in the digital realm. This partnership represents the fusion of expertise, technology, and a shared vision for a future where businesses in Saudi Arabia harness the power of AI and advanced analytics.

For media inquiries, please contact:

Adam Ryan
Chief Data Officer
Adam.ryan@calligo.io
+44 330 124 2500 ext 1120

About Calligo:

Calligo is a global data transformation organization, offering end-to-end solutions from cloud services to cutting-edge machine learning. With a global presence, Calligo is dedicated to unlocking the full potential of data.

About NourNet:

NourNet is a leading digital transformation enabler in the Kingdom of Saudi Arabia, serving corporate clients with a diverse range of digital services. Committed to driving innovation, NourNet plays a pivotal role in the Kingdom’s digital transformation journey.
https://nour.net.sa/

The post Calligo Embarks on Strategic Partnership with NourNet to Drive Digital Transformation in Saudi Arabia appeared first on Calligo.

The post EP 01: When is the artificial truly intelligent? appeared first on Calligo.

The post Our all-new Podcast appeared first on Calligo.

The post Cloud Migration Guides: The Migration appeared first on Calligo.

The post The Data Maturity Impact Report appeared first on Calligo.