Tag: Secure by Design (Consultancy)

Written by Dan Wood – Group CISO – Cyberfort

The Digital Operational Resilience Act (DORA) and the Revised Network and Information Systems (NIS2) standard are two of the latest EU cyber security regulations designed to improve the security posture and cyber resilience of financial services firms.

Both regulations share the same general purpose of increasing their respective sectors’ overall transparency and security. Yet their approaches to this goal vary in several key aspects. In this article we’ll cover:

• Key facts about DORA and NIS2
• The importance of complying with each
• Four main differences between DORA and NIS2
• How the Vanta platform makes compliance easier to manage

What is NIS2?

NIS2 is an EU directive that imposes various requirements and controls on organisations within the Member States to help strengthen their cyber security posture. It’s an extension of the original NIS directive, expanding its scope to additional sectors for more comprehensive coverage.

The directive also introduces stricter and clearer cyber security requirements than its predecessor, as it provides prescriptive guidance in the newer version.

NIS2 came into effect in October 2024, so its implementation is well underway. If you haven’t adjusted your security controls to meet the directives requirements, now is the time to action to avoid potential legal repercussions and financial penalties.

What is DORA?

DORA is an EU regulation that applies to a wide range of financial entities, including banks, investment firms, insurance companies, and payment service providers. Its main goal is to ensure the stability of the EU’s finance and insurance sectors by strengthening their resilience to information and communication technology (ICT) threats.

DORA was enacted on the 16^th January 2023 and the European Commission gave 24 months for its implementation. As of 17^th January, 2025, compliance is mandatory, and the European Supervisory Authorities (ESAs) have already started their activities.

This means that DORA, besides NIS2, is another important regulation financial services organisations should comply with, and there are multiple reasons for this.

Why you should comply with NIS2 and DORA

The main reason to comply with both DORA and NIS2 is to fulfil your regulatory obligations and avoid potentially disruptive compliance gaps that can threaten your organisation’s security posture. Both frameworks prescribe effective cyber security guidelines you should follow to protect your organisation from ever-evolving security threats.

Ensuring timely compliance will help organisations avoid considerable fines, potentially amounting to millions of euros. Both regulations also impose notable non-financial (including holding individuals or management personally liable) penalties in case of violations, which can significantly disrupt an organisations operations.

Even out-of-scope organisations who are not involved in Financial Services can benefit from adopting these frameworks for multiple reasons, including:

Improved cyber security posture: DORA and NIS2 require a granular overview of your security controls, helping you understand your cyber security posture and upgrade it with effective measures.

Operational continuity: Besides the legal and regulatory complications you might encounter if you don’t comply with DORA and NIS2, you can also avoid severe disruptions caused by different types of security breaches.

Industry-wide transparency: Both DORA and NIS2 strive toward an industry-level increase in security transparency in their respective sectors, creating a more stable and trusting operational environment.

Improved stakeholder trust: Demonstrating DORA and NIS2 compliance shows responsibility towards your regulatory obligations and data protection, giving stakeholders more confidence when they engage with your organisation.

Harmonised security compliance: DORA and NIS2 bring together various guidelines from different authoritative sources, offering a holistic approach to cyber security.

The 4 key differences between NIS2 and DORA

While NIS2 and DORA share the same overarching goal and a few general attributes like legal weight and geographic presence, they differ in a few crucial aspects:

Differentiator	NIS2	DORA
Regulation Type	Directive	Regulation
Implementation Deadline	17th October 2024	17th January 2025
Scope	Critical sectors like energy, healthcare, and transport, and MSPs, MSSPs	Financial entities and ICT service providers
Key objective	Mitigation of ICT-related cyber security risks for the financial sector	Strengthening organisations’ overall cyber security posture beyond ICT risks
Focus areas	NIS2 has a broader focus and aims to help organisations strengthen their overall cyber security posture beyond ICT risks	DORA’s main focus is the effective mitigation of ICT-related cyber security risks for the financial sector
Non-compliance penalties	Fines can reach €10,000,000 or 2% of the global annual revenue Top management can be held personally liable	Fines of up to 2% of total annual worldwide turnover or up to €1,000,000 for individuals For ICT providers, penalties of €5,000,000 or up to €500,000 for individuals

The table above covers broad distinctions, but let’s take a closer look at four differentiators that can impact your compliance strategy:

• Regulation type
• Scope
• Focus areas
• Non-compliance penalties

1. Regulation type

NIS2 is a directive, meaning it leaves room for Member States to specify the details regarding its implementation. The specific controls and obligations can vary as long as each jurisdiction can develop an enforceable framework aligned with the directive’s broad requirements.

By contrast, DORA is a regulation, meaning it’s universally applicable to in-scope entities across the EU and doesn’t allow the same leeway as NIS2. The regulation imposes the same rules on all EU Member States and their organisations, making it less interpretative than NIS2.

Despite the differences in implementation, NIS2 and DORA are both mandatory. The latter can be implemented by following the European Commission’s guidance, while NIS2 might require additional guidance from the governing body of your specific jurisdiction.

2. Scope

DORA primarily applies to EU-based financial services organisations and ICT service providers. Several examples of both categories are outlined below:

Entity Type	Examples
Financial Services	• Credit institutions • Trading venues • Credit rating agencies • Account information service providers • Crypto asset service providers • Banks • Investment firms • Insurance and reinsurance undertakings • Payment service providers • Fintech companies • Finserv organisations
ICT services supporting critical or important functions of the financial entity	• Cloud services • Network security service providers • Voice over internet protocol (VoIP) providers • Managed Security Service Providers (MSSP) • Outsourced IT and cybersecurity services • Managed service providers (MSP) • Data centres

NIS2 has a broader scope and encompasses multiple sectors, including:

• Energy
• Transport
• Banking
• B2B ICT service management
• Postal and courier services
• Waste management

Organisations within these sectors can be classified into two categories under NIS2:

Differentiator	Essential Entities	Important Entities
Size Threshold	250+ employees, an annual turnover of €50 million, or a balance sheet of €43 million (varies by sector)	50+ employees, an annual turnover of €10 million, or a balance sheet of €10 million (varies by sector)
Example Sectors	• Health • Water • Digital infrastructure • Energy • Transport	• Waste management • Manufacturing • Digital providers • Postal services • Foods

The classification is based on an organisation’s industry and size. NIS2 primarily targets large and mid-sized organisations, though small businesses and startups might be impacted under specific conditions outlined in Article 2.

While NIS2 applies to a broader range of organisations, financial services organisations and their ICT service providers should prioritise DORA, as it takes precedence under lex specialis. However, organisations subject to both regulations still must comply with NIS2’s general cyber security obligations in areas not fully covered by DORA, such as cross-sector co-operation and information-sharing requirements for critical infrastructure.

Notably, both DORA and NIS2 may apply to your organisation, even if it’s domiciled outside the EU. If you provide services to entities within Member States, you may need to implement at least some of the prescribed controls.

Therefore, organisations must ensure full compliance by meeting both the specific requirements of DORA and the general requirements of NIS2.

3. Focus areas

DORA’s main focus is the effective mitigation of ICT-related cyber security risks for the financial sector. The regulation is built upon five pillars:

ICT risk management: Your organisation needs to have a dedicated control function responsible for identifying, assessing, and mitigating ICT risks.

ICT-related incident management: You need a documented incident response program that encompasses the detection, containment, resolution, and notification of ICT-related incidents.

Digital operational resilience testing: You must develop, implement, and ongoingly review a digital operational resilience testing program that helps you uncover and patch security vulnerabilities.

ICT third-party risk management: DORA requires a robust third-party risk management (TPRM) framework that will simplify the detection and mitigation of third-party ICT risks.

Information sharing: DORA allows (but doesn’t require) entities to exchange cyber threat information with other organisations in the financial sector to increase readiness and transparency.

NIS2 has a broader focus and aims to help organisations strengthen their overall cyber security posture beyond ICT risks. Some of the key cybersecurity risk-management measures encompassed by it include:

• Policies on risk analysis and information system security
• Incident handling
• Business continuity (backup management, crisis management, etc.)
• Supply chain security
• Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure
• Policies and procedures to assess cyber security risk-management measures
• Cyber security training and basic security hygiene
• Cryptography and encryption
• Access control policies, asset management, and human resource security
• Multi-factor authentication (MFA)

Even though both DORA and NIS2 address the security of external parties, NIS2 places a stronger emphasis on supply chain security. Meanwhile, DORA aims to ensure robust third-party risk management, covering a broader range of external service providers.‍

4. Non-compliance penalties

In case of DORA non-compliance, organisations might face various administrative penalties, such as:

• Cease and desist orders for non-compliant practices
• Pecuniary measures as defined by the Member State’s governing body
• Requests for data traffic records

Financial entities are also subject to fines of up to 2% of their total annual worldwide turnover or up to €1,000,000 for individuals. For ICT providers, the penalties stand at €5,000,000 or up to €500,000 for individuals.

Organisations that fail to comply with NIS2 can also encounter non-monetary penalties and criminal sanctions for C-level executives. They may also face substantial fines, specifically:

Essential entities: A maximum fine of at least €10,000,000 or 2% of the global annual revenue, whichever is higher

Important entities: A maximum fine of at least €7,000,000 or 1.4% of the global annual revenue, whichever is higher

Besides lower penalties, important entities face less stringent supervision than essential entities. While essential entities must be more proactive, important entities are subject to ex-post supervision, meaning oversight occurs after evidence of non-compliance or security breaches emerges.

Both NIS2 and DORA can also hold members of management personally liable for cases of gross negligence and wilful misconduct. Still, regulators are not expected to impose personal penalties routinely, enforcement will likely be exercised in extreme cases where non-compliance results from deliberate negligence or a disregard for security obligations.

Given these penalties and oversight differences, determining whether your organization falls under DORA, NIS2, or both is crucial to properly allocate resources.

Should you comply with DORA or NIS2?

Deciding whether to comply with DORA or NIS2 depends on your organisation’s sector. If you’re in the finance industry, you should comply with the former because it takes precedence over the equivalent requirements of NIS2. Otherwise, you may need to pursue NIS2 compliance if the directive applies to your organisation.

Either way, full compliance with these frameworks requires a structured approach. While DORA and NIS2 outline various controls, you might need more detailed prescriptive guidance for thorough implementation.

Without a clear roadmap, you might end up with unnecessarily complex and scattered workflows that can make timely compliance more difficult. To avoid such issues, you should ensure proactive compliance management.

A dedicated trust management platform simplifies this process by automating workflows, centralising documentation, and ensuring real-time compliance tracking, allowing you to achieve DORA and NIS2 compliance with less manual effort.

Ensure NIS2 and DORA compliance with Vanta

From our experience at Cyberfort we have found that Vanta is a comprehensive compliance and trust management platform which helps organisations to automate a significant portion of compliance workflows for NIS2 and DORA. It offers a dedicated NIS2 product that comes with various helpful resources, such as:

• 50+ technical controls
• 100+ document templates
• 600+ relevant tests
• 10+ policies

Combined with over 400+ integrations and advanced automation features, these resources give IT and Cyber Security teams a considerable headstart and improve the workflow efficiency of their compliance processes.

Vanta also offers an equally capable DORA product that simplifies compliance with all the relevant obligations. It can be used to improve an organisations security posture according to DORA’s requirements and ensure robust cyber resilience.

Whether you’re pursuing DORA, NIS2, or both, Vanta will automatically map your organisation’s existing controls to each regulation’s requirements. Doing so prevents duplicate work and lets you achieve compliance faster.

If your organisation would like to find out more about Cyberfort Governance, Risk and Compliance services and how we can help you to deploy the Vanta platform to save time and effort in ensuring you are compliant with NIS2 and DORA email us at [email protected] and one of our experts will be in touch.

Written by Hattie Irving – Cyber Security Consultant

Most organisations rely upon a range of suppliers to deliver products, systems and services to their business to keep them running, operating and delivering for customers. This makes mapping supply chains complex and ensuring they are secure difficult as vulnerabilities can be introduced at any point within the supply chain.

From our experience at Cyberfort we often see many organisations unaware of exactly who is in their supply chain and the security risks posed by different types of suppliers. For example, when was the last time you reviewed your organisations third-party vendors, logistics platforms, SaaS providers and Subcontractors? Each one represents a potential entry point into your business that you didn’t build, don’t control, and probably haven’t had the time to properly scrutinise.

If you don’t have a clear, continuously updated map of your supply chain’s attack surface, you are operating ‘blind’ in a threat landscape that has already figured out where your weaknesses are. In this article we explore the importance of supply chain mapping and its role in mitigating cyber security risks to an organisation.

What is supply chain mapping?

First of all before we delve into the detail of developing a supply chain map it’s important to understand exactly what supply chain mapping is and why it’s key to resilience down the line. Supply chain mapping is considered a form of risk management where organisations need to understand and mitigate the risk in their supply chain. For most this begins with their biggest suppliers and who may have access to their most sensitive data. Unfortunately, this is the stage that the majority of organisations stop at, meaning there are several layers of suppliers who may be operating in your digital environment without the right security certifications, appropriate controls, posture awareness or alignment to your organisation’s security standards.

A thorough supply chain mapping exercise for cyber security purposes is dynamic, technical, and intelligence-driven, not simply a spreadsheet exercise completed once a year before an audit.

It starts with discovery. Not just asking vendors to fill out a questionnaire, but actually identifying every digital touchpoint your organisation has with external suppliers. So what does discovery look like?  It is cataloguing third-party integrations, mapping data flows, identifying what access each vendor has at each privilege level, and understanding ‘shadow IT’ that business units have adopted without security oversight, to name a few. In most organisations, this discovery phase alone can reveal several undocumented connections that no one in the security team knew existed.

From this point, time should be taken to understand the concentration risk. How many of your critical operations depend on a single vendor? What happens if that vendor goes down, or is compromised?

The next layer to map is continuous monitoring. A point-in-time assessment of your supply chain is almost immediately out of date. Vendors change their infrastructure, new integrations appear, security practices are reactive not proactive to the changes, the threat intelligence landscape shifts. An accurate picture of your supply chain risk requires ongoing surveillance, not an annual review.

Finally, you need context. Knowing that a vendor has a vulnerability is only useful if you understand what that vulnerability means for your specific relationship with them. Do they have access to sensitive data? Do they sit upstream of a critical production system? Risk prioritisation requires that context, and building it requires both technical depth and business understanding that most internal security teams are not resourced to deliver.

Illustration 1 – Example of where suppliers might sit within an organisation in terms of their risk profile

Who is considered the highest risk?

Organisations which have privileged access to your systems are widely considered the highest risk factor in your supply chain despite core digital infrastructure being the foundation of your business.

Core digital infrastructure like your cloud provider or internet service provider although underpinning your entire digital business is considered a lower risk due to the cloud responsibility model which ensures cloud providers have to ensure a baseline level of protection of their users data.

The highest risk level sits with managed and professional services which have a wider reach of their own suppliers, greater human risk factors and often direct privileged access into your organisation. Where cloud and ISPs simply host your data they have little direct access into your organisation. Whereas managed services may be responsible for your service desk, identity and access management and potentially terminals into your infrastructure. If one of these partners or users are compromised the attacker will have direct access to your business.

Operational and software vendor risk is inherently lower than that of service providers as the software vendor or code libraries they are using would have to be compromised and persistent access gained for a malicious attacker to get into your environment – although still a high level of impact the likelihood of this happening is considerably lower.

Sub-contractors or any of the suppliers of your cloud hosts, service providers or software are the hardest to map, however should still be considered a risk either of the unknown or ranked by the likelihood of a sub-contractor or supplier being compromised and the effect it would have on your business. Due to its complexity this is often the last aspect of supply chain risk management to be completed as even if you can identify the risk you may not be able to mitigate it.

How can you mitigate risk of supply chain compromise?

Due to the interconnected nature of the digital landscape, completely avoiding supply chain risk is unlikely. But there are key actions you can take to limit your risk and potential exposure to threats via supply chain compromise:

• Ensure your organisation has an up to date and centrally managed Software Bill of Materials (SBOM).
• Track direct and indirect dependencies.
• Reduce attack surface removing unused dependencies and unnecessary features.
• Continuously monitor vulnerabilities.
• Obtain components from trusted sources over secure links.
• Only upgrade dependencies when there is a genuine need.
• Monitor libraries and components which are unmaintained – if they are no longer being patched consider migration to a more secure version or create safeguards around the component.
• Keep CI/CD pipelines updated.
• Stage update deployment and ensure they are tested at each phase.

The question is how many of these actions have you recently undertaken and on what regularity basis? If unsure where to start this should be the time you engage with a supply chain security specialist who can work with you to understand your systems, process and interdependencies in relation to your organisations supply chain. In the next part of this article we explore several of the key actions highlighted above and their importance in the context of mapping your supply chain to reduce cyber risks.

Why a Software Bill Of Materials matters

The software bill of materials (SBOM) outlines which technologies you are using, understanding them is how you can track software vulnerabilities end-to-end and ensure they are remediated in a timely manner. Without fully understanding your in-use technologies you cannot track your tech-debt or vulnerable software. Your SBOM can also inform direct and indirect dependency tracking to understand how code dependencies impact your business operations.

Reducing your attack surface

If you aren’t aware of your SBOM you will struggle to reduce your attack surface, there may be additional products running which are not only unaccounted for but also unmanaged meaning any required updates of the software wont be done, which could leave you liable to zero-day vulnerabilities.

Maintaining updated CI/CD pipelines

Keeping your CI/CD pipeline up-to-date is a key practice for maintaining supply chain security and can be achieved using a series of defined practices:

• Consolidate all CI/CD tooling into a single platform to reduce maintenance overhead and reduce need for context switching for developers.
• Automate as much as you can, ensuring continuous automation can keep security scanning, deployment and infrastructure provisioning running in the background with minimal human oversight.
• Shift left on security – CI/CD pipelines provide a great opportunity to shift security left by implementing security best practices into the pipeline as early as possible to reduce risk and build more inherently secure applications. Shifting left can also prioritise remediation quicker in the deployment pipeline making that last minute panic to patch bugs a thing of the past. Saving time, money and risk of releasing applications which could be compromised.

Tooling to support shifting security left include;

• Static application security testing (SAST) – static tooling analyses code without execution to discover code vulnerabilities.
• Software composition analysis (SCA) – SCA identifies open source code within codebases and automats the process of inspecting package managers, manifests, source code, binary files and container images to generate a SBOM. Using the SBOM the SCA tooling will then compare to databases listing exposed vulnerabilities, licensing issues and code quality issues to enable security teams to best prioritise mitigation.
• Dynamic application security scanning (DAST) – DAST is a form of ‘black box’ testing where tooling will run the live application and find vulnerabilities in its functionality which may not have been identified by SAST.

Vulnerability monitoring

Once you know your technology stack and SBOM you can begin to craft vulnerability management processes to understand which software is vulnerable and any patching or updates you may need to undertake to ensure its security and potentially compliance with key security frameworks your business may be aligned to.

To build an effective vulnerability management process within your organisation first:

1. Produce a SBOM and identify your data flows and their importance within your business.
2. Ensure your systems have a secure configuration – aligning your systems to industry best practices like CIS benchmarking or NIST is a good place to start to avoid potential misconfiguration. Ensure these configuration methods are baked into any builds rather than trying to retrofit security once the deployment has been made.
3. Perform vulnerability, DAST and SAST scanning.
4. Conduct a risk assessment to inform stakeholders what the newly discovered vulnerabilities mean for the organisation. Are they exploitable, which systems do they impact and what is the likelihood of them being exploited.
5. Train employees on security awareness, this should be more than a yearly awareness video, but something more interactive – simulated phishing or vishing to keep staff aware of the threats they face day to day.
6. Perform penetration testing. Although vulnerability scanning is effective to discover any security issues prior to code deployment, penetration testing will validate if your security controls hold up under real-world security testing conditions. Once the pen test has been completed your organisation will receive a report outlining the findings and any security controls which need to be hardened to improve your organisations security.

Final Thoughts

Supply chain attacks have become the preferred entry route for sophisticated threat actors operating today – nation-state groups, ransomware cartels, and cyber espionage operations alike. The reason is simple; they scale. Compromising one upstream vendor gives access to dozens, hundreds, or thousands of downstream targets. The return on investment for the attacker is exceptional.

Meanwhile, regulators are closing in. DORA in financial services, the upcoming UK Cyber Resilience Act, NIS2 across critical infrastructure, and evolving requirements from the UK’s NCSC all increasingly mandate that organisations demonstrate active management of third-party cyber risk, not just contractual clauses hidden in vendor agreements.

The window for treating supply chain security as someone else’s problem is closing. The organisations that move now and take the time to map supply chains, build visibility, monitoring, and response capabilities across their supply chain will be the ones that turn a systemic industry vulnerability into a genuine competitive differentiator.

The ones that don’t will be leaving themselves vulnerable to attacks which could damage reputation, disrupt operations and impact revenue streams.

The key takeaway from this article should be – mapping your supply chain attack surface is not a project with an end date. It is a capability. Building it will require the right expertise, intelligence, and partners for organisations who want to remain secure, resilient and compliant in an ever-changing digital world.

If your organisation is looking to build a vulnerability management system, shift security left under DevSecOps practices, needs support with a software bill of materials or just looking to getting advice and support on how to foster a more secure supply chain environment contact Cyberfort at [email protected] and an expert will be in touch.

Written by Dan Wood – Group CISO – Cyberfort

ISO published the ISO 27001 standard to outline an information security management system (ISMS) in 2005. Since then, significant revisions have taken place in 2013 and 2022 to better reflect the evolving climate of cyber security threats and technologies.  In this article we cover the most current control requirements as established in ISO 27001:2022 and key differences to ISO 27001:2013.

This article will explain how the 2022 version of ISO has evolved from its 2013 predecessor and the current controls that your organisation can implement to become ISO 27001 compliant.

Why was the standard updated?

ISO 27001:2013 served organisations well for nearly a decade, but the threat environment it was written for has evolved significantly. Cloud computing, remote working, supply chain attacks, and the fact that connected devices are used in work and personal lives everyday have all fundamentally altered how risk presents itself. The 2022 revision was designed to reflect the changing threat landscape, aligning more closely with the broader ISO management system framework and incorporating lessons learned from widespread adoption of the 2013 standard.

Organisations that achieved certification under the 2013 version were given a transition period to move to the new standard, with the deadline for full transition set for October 2025. For any organisation who has not started their ISO 27001:2022 journey, it is now more important than ever before to upgrade to the new certification standards.

What are the current ISO 27001 controls?

ISO 27001 controls form the backbone of the ISMS. They are designed to address risks to information security and ensure that critical data remains confidential, available, and integral. The controls are divided into four categories, or themes, under Annex A: organisational, people, physical, and technological measures.

Annex A in the ISO 27001:2013 standard included 114 controls across 14 domains, including access control, cryptography, and incident management. The 2022 update reorganised and modernised these controls to align with cyber security challenges. Instead of 14 domains, the updated controls are grouped into four broader themes:

People: Addressing human factors in security, such as training and awareness

Organisational: Governance, risk management, and compliance practices

Physical: Protection of physical assets and locations

Technological: Safeguarding IT systems and infrastructure

The update aimed to simplify implementation and improve clarity as new threats emerge.

Key differences between ISO 27001:2022
and ISO 27001:2013

The shift from ISO 27001:2013 to ISO 27001:2022 introduced several notable changes:

Reduction and consolidation of controls

The number of controls has decreased from 114 to 93, with several consolidated to eliminate redundancy. For example, cryptographic policies and key management controls are now grouped under a single, streamlined control.

Introduction of “attributes” for enhanced context

‍The 2022 version introduces five attributes to help organisations understand the purpose and application of each control:

• Cyber security concepts
• Information security properties
• Operational capabilities
• Security domains
• Control types (preventive, detective, corrective)

These attributes allow for a more flexible and tailored approach to implementing controls based on organisational needs.

New controls to address emerging threats

‍Fourteen new controls have been added, reflecting advancements in technology and the rise of threats like ransomware and supply chain attacks.  

The main controls which have changed and need to be taken care of in the new standards are arguably the most important thing for IT teams to understand. They were added because they reflect security challenges that were either absent or underrepresented in 2013. From our experience at Cyberfort the main changes in the 2022 version which need to be focused on by IT and Cyber Security teams are:

• Threat intelligence (5.7) — Organisations must now demonstrate that they are actively gathering and acting on information about threats relevant to their environment. Ad hoc awareness of the threat landscape is no longer sufficient; there must be a structured process.
  
  
• Information security for use of cloud services (5.23) — Given how central cloud infrastructure has become to most organisations, the 2013 standard did not address this directly. The 2022 version requires organisations to establish and manage information security policies and controls specifically for cloud usage, covering acquisition, use, management, and exit from cloud services.
  
  
• ICT readiness for business continuity (5.30) — This control formalises the need for ICT continuity planning that is properly integrated into the organisation’s broader business continuity management.
  
  
• Physical security monitoring (7.4) — Surveillance and monitoring of physical premises to detect and deter unauthorised access is now an explicit requirement.
  
  
• Configuration management (8.9) — Secure configuration of hardware, software, services, and networks must be documented, implemented, monitored, and reviewed. This is a control that many organisations believed they were doing well, until they tried to evidence it formally.
  
  
• Information deletion (8.10) — Data deletion requirements, aligned with retention policies and privacy obligations, are now a standalone control rather than embedded within broader data handling guidance.
  
  
• Data masking (8.11) — The use of masking, pseudonymisation, and anonymisation to protect sensitive data is now explicitly required where appropriate.
  
  
• Data leakage prevention (8.12) — DLP as a formal control is a significant addition, requiring organisations to implement measures to detect and prevent the unauthorised disclosure of information.
  
  
• Monitoring activities (8.16) — Continuous monitoring of networks, systems, and applications to detect anomalous behaviour is now a named requirement.
  
  
• Web filtering (8.23) — Management of access to external websites to protect systems from malware and to prevent access to unauthorised web resources.
  
  
• Secure coding (8.28) — Secure software development principles must be applied to internally developed code, reflecting the growing importance of application security in the overall risk picture.

Taken together, these new controls show a clear picture of where ISO expected organisations to have gaps: cloud security, proactive threat intelligence, data governance, and continuous monitoring. For many IT teams, closing those gaps requires capabilities that are difficult to build in-house.

These changes may appear incremental, but they reflect a push toward greater rigour and demonstrability. Auditors will be looking for evidence of intentional, documented decision-making — not just good outcomes.

The transition challenge for IT and Cyber Security leaders

Understanding the changes is one thing. Managing the transition is another. For most IT and cyber security teams, the path from 2013 to 2022 certification involves several concurrent workstreams: gap analysis against the new controls, updating the Statement of Applicability, revising risk treatment plans, updating policies and procedures, and preparing staff for audit under the new requirements.

At the same time, the day job still needs to be completed. Incidents still happen. Projects still demand attention. Budgets still need defending. The result, for many organisations, is that the transition is delayed or delegated to team members who lack the bandwidth or specialist knowledge to execute it effectively. This is the context in which the value of a specialist MSSP and a platform partner like Vanta becomes clear.

How a specialist MSSP Partner can make the difference in achieving ISO 27001:2022

From our experience at Cyberfort helping 100’s of organisations to achieve the new ISO 27001 standard we have discovered that most internal IT teams, however capable, simply do not have time, skills or expertise to upgrade to the new standard on their own.

For example, at Cyberfort we can provide specialist knowledge across the full control set. The new Annex A controls, particularly threat intelligence, DLP, and continuous monitoring, require both technical capability and process maturity. A specialist MSSP will already have these capabilities deployed for multiple customers, meaning organisations benefit from experience that would take years to develop internally.

Continuous monitoring as a managed service, Control 8.16 requires ongoing monitoring of networks and systems. Building a credible in-house Security Operations Centre is expensive and resource-intensive. An MSSP provides this capability as a service, with 24/7 coverage, threat intelligence feeds, and experienced analysts, at a fraction of the cost of a comparable internal function.

Gap analysis and transition support is needed for ISO 27001:2022. A specialist MSSP can conduct a structured gap analysis against ISO 27001:2022, identifying where current controls fall short and providing a prioritised remediation roadmap. This accelerates the transition and ensures that effort is focused where it matters most for certification.

Documentation and evidence management is one of the areas where many organisations struggle the most. During audits it is important that IT and Cyber Security teams can demonstrate that controls are not just in place but are operating effectively. An experienced MSSP helps build and maintain the evidence base – audit logs, configuration records, incident reports, and review documentation, that auditors expect to see.

Supply chain security has a greater emphasis placed on it in the 2022 standard. An MSSP operating across multiple customer environments has broad visibility of supply chain risk patterns and can bring that intelligence to bear on behalf of individual customers.

Finally, achieving certification is not the end of the journey, maintaining it requires continuous attention. An MSSP provides the ongoing management that keeps controls effective, ensures policies are reviewed and updated, and prepares the organisation for surveillance audits without creating resource peaks that can overwhelm internal teams.

Implementing 27001 controls with Vanta

Implementing ISO 27001 controls can seem daunting as discussed earlier in the article. But there is a way forward. At Cyberfort we have partnered with Vanta to deploy and deliver automated compliance platforms to help organisations map existing controls to the updated standard, identify gaps, and implement changes seamlessly.

From our experience at Cyberfort we have seen first-hand how Vanta’s progress tracking and views of tests and controls overlap with complementary standards like SOC 2 and GDPR, which get you closer to multi-standard compliance for a fraction of the effort. The platform’s control mapping feature simplifies understanding how your current ISMS aligns with the 2022 framework, saving time and reducing complexity. Additionally, the platform’s continuous monitoring capability ensures that new controls like cloud service security are actively maintained, reducing the risk of non-compliance.

Final Thoughts

For IT teams, the move from ISO 27001:2013 to ISO 27001:2022 is not simply a compliance exercise. It is an opportunity to modernise the organisation’s security posture, address genuine gaps in cloud security and data governance, and demonstrate to customers, partners, and regulators that information security is taken seriously at every level.

The organisations that will navigate this transition most successfully are those that approach it strategically, treating the new standard not as a checklist to satisfy, but as a framework for building real resilience. A specialist MSSP, with the right expertise and the right compliance platforms like Vanta, is the partner that makes that outcome achievable.

The transition deadline has already passed. The question for IT teams is no longer whether to act, but how quickly they can get there, and who they choose to make the journey with them.

If you want to learn more about how to implement ISO 27001 controls effectively contact us at [email protected] and one of our experts will be in touch.

Introduction

Secure by Design (SbD) was launched in July 2023 and its already transforming the way government departments and the MOD are implementing security. Perhaps one of the biggest changes to UK Cyber Security processes in the last 15 years, Secure by Design aims to ensure all of your systems, processes and data are secure from concept to its launch and then throughout its full lifecycle.

Before we delve deeper into the blog, it’s important to note that MOD Secure by Design and Governmental Secure by design are different. Despite having the same name, the same premise and the same objectives, their execution, delivery and assurance processes are different. They have different principles, different timelines and different maturity levels, with at present MOD Secure by Design being almost fully introduced into MOD programmes and projects. UK Government Secure by design is following suit and is ready to secure projects and systems with its 10 principles.  This article will be looking at the first and most transformative principle, Principle 1: Create responsibility for Cyber Risk.

For the first time, strategic leaders and leadership throughout projects/programmes will be empowered to be responsible and accountable for Cyber Security risk.  Some of these positions will have never encountered Cyber Security before. But by spreading the risk ownership and the understanding across the business/program/project, these projects/programmes will be able to deliver far more secure products and processes, with a far greater security lifespan.

Addressing the elephant in the room – businesses have never been the biggest lovers of major change. To understand these large scale governmental Secure by Design changes it’s important to know why these changes are being implemented, and to understand the benefits of Secure by Design.

Unlocking the Benefits of Secure by Design Principle 1 – Create responsibility for Cyber Risk

A key benefit of Secure by Design is how it affects leadership. Leaders at every level are decision makers and greater understanding of Cyber Security and its risks will ensure that leaders make better decisions.  By implementing Secure by Design principles leaders are able to make informed decisions, and better decisions will be made when leaders understand cyber risks. This empowerment towards leadership is not just at the executive level, it cascades down, resulting in leaders at all levels having an understanding of cyber risk and ensuring it is understood and mitigated. This creates a much more comprehensive risk understanding and security controls that are better informed, and therefore far more fitting.

Too often there is a disconnect between executive leadership and the technical teams responsible for securing systems. This gap can result in poorly informed decision-making, lack of investment, and incorrect prioritisation of risk mitigation. By clearly assigning cyber security responsibilities to stakeholders, such as CEOs, COO’s as well as Chief Risk Officers and Board Members, organisations ensure that cyber risk is treated alongside financial, legal, and operational risks.

Another major benefit of Secure by Design is that it aims to stop Cyber Security work being siloed, or existing in isolation. Cyber Security attackers will normally attack a wide surface, not just the security function, and so security needs to be in the forefront of everyone’s minds. By empowering security to staff throughout the business, rather than just the security team it not only spreads awareness but deepens the security scrutiny and allows security to be looked at from subject matter experts, potentially highlighting weaknesses that a cyber security team member would not be able to see.

A case study of where specific expertise has been siloed can be seen within NASA in the 1970’s, specifically during the challenger builds. Engineering teams identified that the ‘O rings’, a component of the lower rockets could fail, which could in turn lead to the entire failure of the launch. This severe risk was not fully understood by senior stakeholders’, and their findings were siloed within the rocket engineering team, unable to get their extreme risk findings correctly communicated or mitigated. This tragically led to the destruction of Challenger on launch and the loss of her entire crew.

By having all teams empowered to not just understand security risks but have influence over them gives the opportunity for projects and programmes to be more secure. Most organisations already do this for safety, and so security will now be no different.

The key challenges organisations must overcome

Of course, as with any organisational change there are challenges. The largest challenge so far observed in the Secure by Design rollout is leaders who are newly empowered to be responsible or accountable for cyber security being unwilling or unable to fully immerse themselves into the new role.

Many leaders face busy days, heavy workloads and hold a lot of responsibility already. With the changes being made some are being informed that they must take on more responsibility in an area they may be unfamiliar with. They may not welcome the changes and therefore will not commit to them as intended. A potential sign of this may be them trying to delegate this responsibility to another team member or someone within their team, pushing work deadlines back indefinitely or openly stating that they are going to refuse to partake. This unfortunately will mean that the delegation of security accountability at all levels will not be being implemented correctly, and that person is not only creating risk but a risk themselves.

The best way to remedy this so far has been to educate these leaders in the importance of the security work and the new responsibility they hold, and to ensure that their workload is balanced well enough that they can correctly adapt to the changes.

Final Thoughts

The first principle of Secure by Design sets the tone for the entire framework: security begins with leadership. When executives take ownership of cyber risk, they signal its importance throughout the organisation. They unlock the necessary resources, drive cultural change, and support the technical teams in making security a core part of every decision, and creating programmes, systems and projects that are secure, by their design.

As cyber threats continue to evolve in scale and sophistication, especially with AI and quantum threats on the horizon, creating clear responsibility for cyber security risk is not just good practice, it’s now an essential pillar of resilience.

How Cyberfort can help?

At Cyberfort we specialise in helping organisations understand their comprehensive cyber risk landscape and put the best governance in place. We ensure cyber security and resilience is built into systems, processes and policies from the start of a product or service lifecycle. This enables organisations to align security with business objectives, existing systems, and industry regulations consistently.

Our teams are experienced in aligning business strategy with Secure by Design principles, starting with clear responsibility at the top. If you’re ready to take a proactive approach to cyber resilience, contact us at [email protected] or visit our website here.

Secure by Design sets a framework of Principles for the delivery of digital capability with cyber security and risk management at the core. This blog article explores how continual assurance measures: Vulnerability Management and Security Controls Testing ensure that delivery Principles including Principle 5: Build in Detect and Respond Security and Principle 7: Minimise the Attack Surface continue to be effective through-life by implementing Principle 9: Embed Continuous Assurance.

Vulnerability Management is a critical component of ongoing security assurance, providing risk owners with continuous evidence that the system’s security controls and capabilities are functioning as intended. This assurance spans the full lifecycle of a system from development to deployment and into ongoing operation.

Security Controls Testing verifies that security controls and capabilities continue to function as intended, especially after deployment and during system operation. Combined, they support the application of Secure by Design, building a resilient security posture.

Key Benefits of Vulnerability Management and Controls Testing

Secure by Design principles embedded into the development process, ensures that activities and controls such as threat modelling, secure coding, continuous testing, access controls, encryption and monitoring have validation mechanisms in place. In the next section of this article, we explore what the key principles are for vulnerability management and controls testing, highlighting the key benefits organisations can realise by adopting a Secure by Design approach.

Risk Mitigation and Management
Principle 5; emphasises proactively embedding detection and response mechanisms into systems and services during design and development, and not as an afterthought. This foundation allows vulnerability management to be more proactive, focusing on preventing vulnerabilities rather than just reacting to them. These Secure by Design controls serve as baselines, enabling automated detection of deviations or misconfigurations.

Ongoing vulnerability management supported by controls testing ensures that risk mitigation continues to be effective. Vulnerability identification, assessment and remediation provides risk owners the evidence that continuous monitoring validates that controls remain effective against evolving threats.

By documenting vulnerability trends, patch cycles, and remediation effectiveness, organisations can demonstrate compliance with internal security standards and regulatory requirements.

Security Controls Testing confirms that identified security controls remain effective in mitigating risks over time. This provides evidence that risk management remains effective, giving confidence that security posture across the system’s lifecycle remains.

Sustaining an excellent security posture after deployment is crucial, as systems can become vulnerable due to configuration drift, outdated software, or new threat vectors. Continuous validation through testing identifies where changes may have occurred and provides opportunity to resolve them, realising several benefits:

• Security measures continue to deliver protection as intended.
• Controls are not bypassed or degraded over time.
• The service continues to mitigate known and emerging risks.

Verifying operational effectiveness of controls post-deployment, ensure that updates, patches, or changes have not compromised system security and that security policies are applied and enforced. This helps to identify deviations from approved baselines or misconfigurations and prevents drift from security standards that can introduce new vulnerabilities.

Tracking Progress and Maturity
Ongoing vulnerability management and through-life controls testing helps track how effectively the implementation of Secure by Design principles are across the organisation including:

• Trends, gaps, and analysis of recurring issues can help to refine the secure development lifecycle and ensure continuous improvement.
• Metrics from vulnerability management such as time to patch, frequency of critical vulnerabilities, or compliance with baseline configurations support strategic objectives.
• Track maturity in Secure by Design adoption.
• Identify gaps in implementation or effectiveness.
• Adapt and improve processes to close those gaps, aligning with continuous improvement.

Reinforcing Secure by Design Through-Life
Vulnerability management is central to the success of other Principles, supporting the measures adopted by validating that they remain effective or providing opportunity for improvement. It covers the ‘Detect’ part of ’Detect and Respond Security.’  and involves continuously:

• Identifying known weaknesses (e.g., unpatched software, misconfigurations).
• Assessing the risk and severity of those vulnerabilities.
• Prioritising and remediating based on impact.
• Monitoring for signs of exploitation.
• Testing to confirm resolution of vulnerabilities and that they do not reappear.

Integrating Vulnerability Management with other through-life assurance and operational measures ensures a more robust security management programme. These include:

• Controls Testing: Regular testing validates that security controls (like patch management, access controls, logging) are effective in mitigating vulnerabilities and risks.
• Logging, Monitoring & Alerting: Vulnerability scanners, SIEM tools, and endpoint detection systems provide real-time visibility into potential threats exploiting known weaknesses.
• Incident Detection & Response: When a vulnerability is exploited, fast detection and coordinated response limit damage and prevent recurrence.
• Continuous Iteration: Threat landscapes evolve, so vulnerability management must be a continuous process, not a one-time event.

Having minimised the attack surface (Principle 7) during the design and build of the capability, Vulnerability Management and Controls Testing helps to identify new attack vectors and validate that the capability can remain resistant.

Continuously scanning for and identifying known security weaknesses across systems, applications, and networks – detects vulnerabilities early.
• Unnecessary or outdated services/components can be disabled or removed.
• Exposed ports, APIs, or services can be secured. This reduces the number of potential entry points, shrinking the attack surface.

Vulnerabilities are prioritised based on severity, exploitability, and asset criticality:
• Issues are prioritised, preventing adversaries from targeting easily exploitable paths.
• Unused or low-utility components that present elevated risk can be removed or replaced.

Vulnerability management often uncovers over-privileged accounts or services, or components running with unnecessary permissions.
• Controls Testing identifies if gaps exist and then by remediating these findings, organisations can enforce the principle of Least Privilege and Minimised Functionality.
• These improvements ensure that only essential capabilities are exposed.

Vulnerability data informs threat models.
• Helps understand real-world attack vectors and the likelihood of compromise.
• Supports asset and risk management in focusing mitigation efforts where they matter most.

Ongoing vulnerability assessments ensure newly introduced components do not expand the attack surface unnecessarily. Supported by Controls testing, this validates that updates, patches, and configuration changes have not inadvertently reintroduced risk.

Vulnerability management is not just a technical function it is a continuous, evidence-based assurance process. When integrated within Secure by Design practices, it provides risk owners with confidence that security measures are both present and effective, supports the detection and resolution of implementation gaps, and helps ensure that systems remain resilient throughout their operational life.

Understanding the key challenges

Vulnerability management plays a crucial role in upholding Principle 5 and Principle 7, which emphasises the need for integrated capabilities to detect, respond to, and recover from security incidents. Principle 7 advocates reducing the number of exploitable points in a system, but in practice, achieving this while managing vulnerabilities is complex. Consequently, aligning vulnerability management practices with this principle comes with several challenges:

Visibility Gaps & Poorly Defined Ownership and Responsibilities:

• Challenge: Incomplete asset inventories, and unmonitored/unscanned systems make it hard to detect vulnerabilities across the full attack surface. The lack of clarity over who owns which assets or components with users/developers unknowingly increase the attack surface.
• Impact: Undetected vulnerabilities in these “blind spots” if exploited, hinder both detection and timely response. This leads to gaps in vulnerability remediation, attack surface monitoring, misconfigurations, unsafe code practices, and ignored security guidance.

Integrating DR Tools with Complex and Dynamic IT Environments:

• Challenge: Modern infrastructures (cloud, containers, microservices) changing rapidly and the lack of integration between vulnerability scanners and SIEM (Security Information and Event Management) and/or EDR (Endpoint Detection & Response) platforms.
• Impact: The constant changes make it hard to maintain an up-to-date view of the attack surface and it also limits the ability to correlate vulnerabilities with active threats or incidents, reducing effectiveness in prioritising or automating responses

Prioritisation of Risks & Patch Management Delays:

• Challenge: Security teams may struggle to prioritise which vulnerabilities require immediate attention due to limited context (e.g., threat intelligence, exploitability, asset criticality). Once they have decided on a priority, patching can cause downtime or affect business operations, leading to delays.
• Impact: Prolongs vulnerability exposure, especially in high-risk systems. Time and resources may be wasted on low-risk issues, while critical threats remain unaddressed.

Outdated Vulnerability Data and Integrating Legacy & Complex System Updates:

• Challenge: Modification, update or decommissioning of older systems often results in significant cost or disruption. Careful consideration must be taken when updating components (e.g., third-party libraries, firmware, OS) as these can break existing functionality or introduce new vulnerabilities. And relying on outdated vulnerability databases or incomplete scanning (e.g., failing to detect zero-days or misconfigurations) does not help. Legacy systems may not have been developed with SbD principles in mind and can have undocumented vulnerabilities.
• Impact: These systems increase the attack surface and may have un-patchable vulnerabilities. They can introduce weaknesses or incompatibilities in otherwise secure environments. This weakens the ability to proactively detect or prepare for exploitation attempts. It also becomes difficult to ensure that security controls still function post-update.

Organisational Silos:

• Challenge: Vulnerability management is often handled by separate teams from incident response or threat detection.
• Impact: Creates communication gaps, slows coordinated response, and leads to disjointed security workflows.

How a specialist Cyber Security Provider can help organisations to address these challenges

To help organisations overcome these challenges organisations who do not have the in-house skills, expertise or knowledge should engage with a specialist cyber security services provider. A reputable cyber security services provider should have a track record of and be able to deliver holistic and managed cyber security services which keeps people, data, systems, and technology infrastructure secure, resilient, and compliant. For example, at Cyberfort  we provide National Cyber Security Centre assured Consultancy services that leverage our technology, hosting, and Security Operations capabilities to Identify and protect against cyber-attacks, detect and respond to security incidents.

Our Managed services provide vulnerability management that integrates with threat detection capabilities, connecting scanners with SIEM and/or EDR platforms for better context and automation.

• We use Risk-Based Prioritisation, leveraging common risk and severity scoring methods such as CVSS, asset values, exploit availability, and threat intelligence to prioritise vulnerabilities.
• We implement continuous monitoring as a shift from periodic scanning to continuous assessment and detection.
• We break down silos and encourage cross-team collaboration between vulnerability management, SOC, and IT operations.

Additionally, we reinforce the continuous monitoring regimes through proactive and reactive controls testing. Reactively done in response to risk or incident resolution, providing assurance that controls are in place and effective. Proactively testing controls baselines can be crucial for either identifying controls weaknesses which lead to risks or mitigating issues before they become risks in the future by validating controls are effective. Whilst vulnerability management tends to focus on the technology landscape, controls testing can consider validation of the people, process, and procedural controls.

Reactive testing from external audits has included the review of Joiners, Movers, Leavers (JML) processes, to identify issues within the Leavers part of the current JML process that is in place that were resulting in unrevoked accounts.

Proactive controls testing conducted as a gap analysis against expected policy implementations to ensure that conformance by the business and those supporting the business in functions. An example of this validated that contractors with permission to craft and modify code held the correct vetting status, as per the businesses vetting policy set in place by the CISO.

Final Thoughts

Vulnerability management in the context of security assurance across the system lifecycle is challenging because it demands continuous effort, adaptation, and validation. It can however be effective in minimising the attack surface when integrated with asset discovery, risk analysis, and threat modelling. Organisations can increase the security return on investment and comply with the security principle of “necessary and sufficient” using only what’s required to deliver a secure, functional service.

Security Controls Testing within the ‘Secure by Design’ lifecycle ensures that security controls operate effectively throughout the system lifecycle, not just at deployment of a system going live. When integrated correctly into a Secure by Design security programme, it delivers continuous assurance to risk owners by validating the ongoing mitigation of risks, enabling timely detection of failures, and reinforcing organisational security posture, while also proactively identifying and closing gaps before risks arise.

While Secure by Design embeds security into every stage of the system lifecycle, ensuring that it continues to perform as intended, requires more than simply good initial design. These through-life concepts and Principles, delivered effectively can allow organisations to respond to the changing threat landscape, minimising the impact of systems becoming vulnerable, but this requires effective threat intelligence and resources to maintain the services.

For more information about Cyberfort Secure by Design consultancy services and how we can help your organisation to become secure, resilient and compliant contact us at [email protected].

In this article Cyberfort security experts discuss why threat modelling is a crucial strategic capability which enables organisations to proactively identify and mitigate cyber risks before they materialise. This capability when embedded within governance and aligned with the UK Government’s Secure by Design principles, becomes a repeatable, auditable, and measurable part of the security lifecycle supporting resilience, trust, and long-term value.

Understanding Threat Modelling and its importance to a Cyber Security strategy

At its core Threat Modelling is a structured process for identifying potential threats and vulnerabilities to a system, enabling teams to prioritise and implement mitigations before any thoughts of deployment are made. It is not a one-off audit but a repeatable, analytical exercise that integrates security into the design phase, ensuring that systems are ‘Secure by Design’.

Cyberfort understands that in today’s rapidly evolving digital landscape, organisations can no longer afford a reactive security posture. With expanding attack surfaces and increasingly sophisticated threats, businesses face the growing challenge of building resilience and trust into the core of their operations. Threat modelling offers a comprehensive and practical framework to achieve this goal, by providing a systematic process for identifying and addressing design flaws early.

To be effective, threat modelling must begin with a clear understanding of the organisation’s digital estate. Comprehensive asset discovery, covering applications, data, APIs, and infrastructure, is essential to minimising the attack surface and sourcing secure and supported technology products must be at the centre of any digital project. These secure approaches ensures that threat modelling is grounded in reality and supports informed decision-making.

A well-informed threat modelling process relies on a current and accurate understanding of the threat landscape. This begins with sourcing a threat assessment, to understand the current threats to the business and industry. This is a core activity within the risk driven approach. The outputs, probability and impact are used to generate a threat score, which should directly inform the Data Flow Diagram (DFD) and prioritisation during threat modelling workshops.

Scoping the threat modelling effort should be deliberate and focused. Starting with a manageable, business-critical system allows teams to iterate and build confidence. This supports making changes securely, ensuring that changes are incremental and security is considered early and consistently throughout the lifecycle.

Threat modelling must also integrate with broader security controls frameworks, so that identified threats lead to actionable controls. This reflects the principle to design usable security controls and, where necessary, prompts system redesign to defend in depth and design flexible architectures that can adapt to evolving threats.

Threat modelling outputs inform risk management, enhance SOC capabilities to build in detect and response security, guide architectural decisions, and strengthen third-party risk assessments. These insights also feed into business continuity and disaster recovery planning, helping organisations anticipate threats that could impact critical business functions. This cross-functional integration supports the principle to embed continuous assurance and ensures that security is not a one-time effort but a sustained end to end practice.

Governance – Embedding Threat Modelling

For threat modelling to be sustainable and effective strong governance must support it. This ensures the activity is not ad hoc, but a formalised part of the organisation’s security lifecycle, aligned with the principle to create responsibility for cyber security risk.

Integration with risk management and key service functions is another foundation of success. Since threat modelling is fundamentally a risk reduction exercise, it must be closely aligned with the business risk framework. This allows threats to be assessed, prioritised, and tracked effectively.

Organisations should update security policies to mandate threat modelling for all new systems, major changes, and high-risk projects. Minimum requirements should be defined for when and how threat modelling is conducted, with clear roles and responsibilities established. Integrating threat modelling into governance and project gates, such as design reviews and change control boards, ensures it becomes a required control, not an optional activity.

To build confidence and ensure quality, threat models should undergo peer review by experienced security professionals. Checklists and quality criteria help assess completeness and relevance, while periodic audits ensure models remain current. Aligning validation with internal audit and compliance reviews demonstrates due diligence and supports the principle to build in detect and respond security.

Finally, to support scalability and consistency, organisations should adopt structured and automated tools such as Microsoft’s Threat Modelling Tool or OWASP Threat Dragon. These platforms enable repeatable, auditable practices and align with Secure by Design’s call for robust, risk-driven security governance.

Threat Modelling and Shift Left Security

Modern cyber resilience demands that organisations move beyond reactive security and embrace a proactive, risk-based approach, one that identifies and mitigates vulnerabilities early in the development lifecycle. This is the essence of the Shift Left philosophy, and it aligns directly with several Secure by Design principles, including designing usable security controls, making changes securely, and embedding continuous assurance.

By shifting security left, organisations reduce the cost and complexity of remediation while improving the overall quality and resilience of their systems. This proactive posture supports the goal of creating responsibility for cyber security risk across teams, from developers and architects to business leaders and risk owners.

Threat modelling plays a central role in this strategy. By analysing systems during the design phase, organisations can identify potential threats and vulnerabilities before they are coded into production. This early intervention supports the principle to minimise the attack surface and ensures that security is built in from the start.

Integrating threat modelling with vulnerability management creates a powerful feedback loop. Threat models help prioritise which threats and vulnerabilities matter most, based on business impact and exploitability, allowing teams to focus on what truly needs fixing. This supports the principle to adopt a risk-driven approach, ensuring that resources are directed toward the most critical risks.

Moreover, when threat modelling is embedded into agile and DevOps workflows, it enables continuous validation of security assumptions. This aligns with the principle to build in detect and respond security, as teams can monitor for deviations and respond to emerging threats in real time. It also reinforces the importance of defending in depth, by ensuring that multiple layers of controls are considered and implemented from the outset.

Implementing Threat Modelling

Effective threat modelling begins with ensuring the right expertise is in place. Skilled threat modellers are essential to the success of any programme, and organisations should consider investing in certified threat modelling training or broader security architecture courses that include threat modelling components. Building internal capability or bringing in experienced threat modelling professionals.

Selecting the right threat modelling methodology is equally important. The framework should align with the organisation’s risk appetite, technical environment, and business goals. Popular methodologies include:

STRIDE-LM, which categorises threats into six types – Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege and Lateral Movement

PASTA (Process for Attack Simulation and Threat) offers a risk-centric approach that simulates attacks and aligns with business impact.

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) provides a comprehensive, real-world knowledge base of adversary tactics and techniques, helping teams map threats to known behaviours and improve detection and response.

To scale threat modelling across multiple projects and teams, organisations should leverage automated tools such as Microsoft Threat Modelling Tool or OWASP Threat Dragon, these tools streamline the modelling process, improve consistency, and reduce manual effort, making it easier to embed threat modelling into agile and DevOps workflows and technologies like SIEM and continuous assurance platforms.

Senior leadership engagement is critical. Threat modelling must be embedded into governance structures and mandated as part of project lifecycle gates. Executive sponsorship ensures that threat modelling is prioritised, resourced, and aligned with strategic objectives.

Additionally, outputs from threat modelling should be actively consumed by operational teams such as the Security Operations Centre (SOC), which can use them to enhance threat detection and monitoring; Incident Management, which can develop response playbooks based on modelled scenarios; and Business Continuity and Resilience teams, which can ensure continuity plans address realistic threat vectors and create appropriate business continuity plans. This cross-functional integration ensures that threat modelling insights are actionable and drive improvements across detection, response, and recovery capabilities.

Why Use a Specialised Threat Modelling Consultancy?

As organisations weigh up the decision to implement threat modelling, one crucial consideration is whether to build the capability in-house or to engage a specialised consultancy like Cyberfort. While internal teams bring valuable domain knowledge, engaging a specialist consultancy offers several distinct advantages. 

Specialised consultants bring deep expertise in both the technical and procedural aspects of threat modelling. They will have typically worked across various industries and methodologies, enabling a tailored approach to each client’s unique risk appetite and technical environment. This accelerates implementation and reduces the risk of error or oversight.

A specialist cyber security provider can also offer an objective perspective, which is essential when analysing complex systems. Internal teams may inadvertently overlook critical threats due to familiarity bias.  Trained and experienced consultants will be able to conduct rigorous, unbiased assessments, identifying gaps that may otherwise go unnoticed.

Additionally, an experienced consultancy partner will be  adept at integrating threat modelling into governance structures and development workflows (Shift Left), ensuring it becomes a sustainable practice, not a one-off project. They will provide the tools, templates, and training to build internal competency.

For many organisations, particularly those with limited security architecture expertise, this efficiency can mean the difference between a theoretical exercise and a practical, value-driven programme. At Cyberfort we can do more than guide implementation; we become a strategic partner in building a mature, proactive security posture.

Final Thoughts

Finally, threat modelling should be a continuous and integrated activity throughout the lifecycle of enterprise IT and digital projects. Security assurance must not be limited to initial design phases but should extend through development, deployment, and ongoing operations. By embedding threat modelling into each stage and enriching it with real-time threat intelligence, organisations can maintain alignment with the evolving threat landscape.

The return on investment from adopting threat modelling is multifaceted. It improves security outcomes, reduces remediation costs, enhances stakeholder confidence, and promotes operational discipline. It enables organisations to innovate with confidence, knowing that their systems are designed to be secure from the start.

Threat modelling should be viewed not as a technical checklist but as a strategic enabler. It supports business growth by providing a reliable framework for managing risk, protecting assets, and demonstrating trustworthiness. As organisations continue to evolve digitally, the importance of a proactive and adaptive security practice will only grow.

The journey begins with a commitment to building security in, not bolting it on. With a clear plan, engaged leadership, and the right expertise, threat modelling can become a powerful tool for long-term success and sustainability.

In a world where the threat landscape evolves daily, assuming your systems are secure is a strategic gamble. Threat modelling replaces assumption with analysis and hopefully, with evidence. It is the foundation of a truly resilient organisation, capable of building with confidence and facing future threats head-on.

For more information about Cyberfort Secure by Design consultancy services and how we can help your organisation to become secure, resilient and compliant contact us at [email protected].