Threat Modeling for ISO 27001, NIS2 and DORA

Anya, the CISO of a fast-growing fintech company, was asked to approve a launch plan for a new B2B payment-risk platform. The board wanted market entry before the end of the quarter. Sales had already lined up banking customers. Engineering had sketched a cloud-native architecture with identity attributes, device signals, transaction metadata, behavioural risk scores, a managed database and a third-party analytics provider.

On paper, the platform looked like a commercial breakthrough. To Anya, it looked like five compliance conversations arriving at once.

As a financial technology provider, the company had DORA pressure. As a cloud service and digital platform provider, it needed to understand NIS2 exposure. Because the platform processed personal data relating to EU individuals, GDPR applied. Enterprise customers expected ISO/IEC 27001:2022 certification. If the service became part of a connected software product, Cyber Resilience Act expectations would add secure-by-design product evidence.

The development team proposed the usual security plan: scan dependencies, run a vulnerability scan, book a penetration test and patch the critical findings before go-live. Anya knew that was not enough. Those activities test what has already been built. They do not prove that the architecture was secure by design, that trust boundaries were understood, that personal data flows were minimised, that supplier assumptions were reviewed, or that service disruption scenarios were considered before launch.

So she slowed the meeting with four questions:

1. Where are the trust boundaries?
2. Which abuse cases could lead to fraud, data exposure or service disruption?
3. Which design decisions reduce the risk before code is written?
4. What evidence will satisfy ISO 27001, NIS2, DORA, CRA and GDPR reviewers six months from now?

That fourth question is where many organisations fail. Threat modeling is often treated as a useful engineering workshop, then buried in a wiki page. In 2026, that is not enough. For SaaS providers, fintech firms, cloud platforms, MSPs, MSSPs, digital infrastructure operators and software manufacturers, threat modeling has become a compliance evidence engine.

A mature threat modeling process turns STRIDE findings, abuse cases and architecture decisions into risk register entries, security requirements, treatment plans, test cases, supplier assurance tasks, privacy-by-design evidence and Statement of Applicability traceability.

Why secure-by-design evidence now matters

Modern regulations are converging around the same expectation: organisations must identify security and privacy risks early, assign ownership, implement proportionate controls and retain evidence.

ISO/IEC 27001:2022 requires a risk-based information security management system. Clauses 6.1.2 and 6.1.3 require information security risk assessment and treatment. Clause 8.1 requires operational planning and control. Annex A provides controls that must be selected through the Statement of Applicability based on risk, legal requirements and business needs.

NIS2 brings the same principle into cybersecurity governance. Article 20 requires management bodies to approve cybersecurity risk-management measures and oversee implementation. Article 21 requires appropriate and proportionate technical, operational and organisational measures, including risk analysis, incident handling, business continuity, supply chain security, security in acquisition, development and maintenance, vulnerability handling, cyber hygiene, encryption, access control, asset management and MFA where appropriate.

DORA applies a financial-sector operational resilience lens from 17 January 2025. It requires covered financial entities to maintain a sound, comprehensive and documented ICT risk management framework, identify ICT assets and dependencies, apply protective and preventive measures, detect anomalous activity, test digital operational resilience, manage ICT third-party risk and prepare response and recovery capabilities. For covered financial entities, DORA is the sector-specific Union legal act for overlapping NIS2 obligations.

GDPR adds accountability and data protection by design and by default. Any system processing personal data must be able to demonstrate lawful, fair, transparent, purpose-limited, minimised, storage-limited and secure processing. A threat model that maps personal data flows, access paths, logs, retention, deletion and third-party transfers is directly relevant to GDPR Articles 5, 25, 32 and 35.

The Cyber Resilience Act adds pressure for products with digital elements. Product teams need lifecycle evidence showing cybersecurity risks, foreseeable misuse, interfaces, update mechanisms, authentication flows and vulnerability-handling assumptions were considered early.

The lesson is clear: if an architecture review cannot be traced to risks, controls, owners, mitigations and tests, it will be hard to defend in a 2026 audit or regulatory review.

The Clarysec model: one threat model, many outputs

Clarysec’s approach starts with a practical principle: a threat model is not complete until it produces auditable decisions.

In Zenith Blueprint: An Auditor’s 30-Step Roadmap [ZB], the Risk Management phase, Step 9, gives teams a simple format for converting technical observations into risk language:

“Now combine Asset + Threat + Vulnerability into a concise risk scenario description. Essentially, describe the potential incident. This will later be a line item in your Risk Register. Use a simple format: ‘[Threat] exploits [vulnerability] on [asset], resulting in [impact].’”

That sentence is the bridge between engineering and compliance.

A whiteboard note such as “partner API spoofing risk” becomes:

“An attacker exploits weak partner API authentication on the transaction-risk API, resulting in unauthorised access to payment-risk decisions and personal data exposure.”

Now the finding has an asset, threat, vulnerability and impact. It can be assessed, assigned, treated, tested and accepted.

The policy layer makes this repeatable. The P24 Secure Development Policy [P24] states:

“All new applications and major changes must undergo secure architecture review and threat modeling before development begins.”
From section “Policy Implementation Requirements”, policy clause 6.1.1.

It also requires:

“Design reviews must document data flow diagrams, trust boundaries, and mitigation measures for identified risks.”
From section “Policy Implementation Requirements”, policy clause 6.1.2.

Those two clauses are powerful audit anchors. They show that threat modeling is not optional and that design evidence must include diagrams, boundaries and mitigation decisions.

The P06 Risk Management Policy [P06] connects threat modeling to enterprise risk management:

“All business units shall proactively identify risks using structured techniques derived from ISO/IEC 27005:2024, including threat modelling, asset dependency mapping, and scenario-based identification.”
From section “Policy Implementation Requirements”, policy clause 6.1.1.

It also states:

“Identified risks shall be documented with reference to the asset owner, threat actor, vulnerability, and potential impact on Confidentiality, Integrity, and Availability (CIA).”
From section “Policy Implementation Requirements”, policy clause 6.1.4.

This is the evidence chain auditors want to see: policy requirement, design activity, risk scenario, control selection, implementation, testing and approval.

STRIDE makes coverage systematic, abuse cases make it real

STRIDE remains one of the most useful methods for design-stage threat modeling because it forces teams to consider six common failure modes:

• Spoofing
• Tampering
• Repudiation
• Information disclosure
• Denial of service
• Elevation of privilege

For Anya’s payment-risk platform, the team used STRIDE across each component, data flow and trust boundary.

Spoofing raised the question of whether a partner API client could impersonate a banking customer if mutual authentication was weak. Tampering exposed the risk that device signals or transaction amounts could be manipulated before ingestion. Repudiation highlighted the need for administrator and transaction audit logs. Information disclosure focused on leakage through logs, analytics exports, support tools and reporting APIs. Denial of service forced the team to consider peak transaction windows and malformed request floods. Elevation of privilege exposed risks in support roles, session tokens and administrative functions.

Abuse cases converted those categories into real stories:

• A fraudster uploads manipulated device signals to influence a risk score.
• A compromised partner credential floods the API with fraudulent requests.
• A developer uses production personal data in a test environment.
• A malicious insider exports customer identifiers and scoring logic.
• A cloud analytics supplier outage blocks risk decisions during a payment window.
• A storage misconfiguration exposes uploaded identity documents.
• A deletion workflow removes the application record but leaves backups and supplier copies.

Each abuse case became a design-risk record with the affected asset, threat actor, vulnerability, impact, existing assumptions, required mitigation, residual risk owner, test evidence and regulatory relevance.

That structure prevents vague findings such as “API security risk.” It produces evidence-grade risk statements such as:

“An attacker uses stolen partner credentials to submit fraudulent scoring requests through the transaction-risk API, resulting in integrity compromise of risk decisions, possible financial loss for customers and unauthorised processing of personal data.”

Mapping threat modeling to ISO/IEC 27001:2022 and ISO/IEC 27002:2022

ISO/IEC 27001:2022 does not require threat modeling by name. It requires consistent, documented risk assessment and risk treatment. Threat modeling is one of the strongest methods for generating that evidence in software, cloud and product environments.

The key is traceability. In ZB, the Risk Management phase, Step 13, recommends mapping controls to risks and clauses, including Annex A references in treatment plans and noting where controls support GDPR, NIS2 or DORA.

Zenith Controls: The Cross-Compliance Guide [ZC] helps structure that traceability by mapping ISO/IEC 27002:2022 controls to related controls, audit expectations and external frameworks.

For threat modeling, ISO/IEC 27002:2022 control 5.8, Information security in project management, is the project governance anchor. It shows that security is integrated into project initiation, planning, execution and acceptance.

Control 8.25, Secure development life cycle, is the SDLC anchor. ZC connects 8.25 to supporting controls such as 8.26 application security requirements, 8.27 secure system architecture and engineering principles, 8.28 secure coding, 8.29 security testing in development and acceptance, 8.30 outsourced development and 8.31 separation of development, test and production environments.

This mapping helps turn a design workshop into Statement of Applicability evidence. It also supports ISO/IEC 27001:2022 clauses 4 through 6 because interested-party requirements, ISMS scope, leadership commitments and risk treatment decisions are all visible.

A cross-compliance map for NIS2, DORA, CRA, GDPR and NIST CSF

A well-run threat model should not produce five disconnected compliance workstreams. It should produce one design-risk evidence pack that can be reused across frameworks.

NIST CSF 2.0 is especially useful for executive communication. Its GOVERN function supports legal, regulatory, contractual and privacy obligations, while its supply chain outcomes help connect supplier criticality, contractual requirements, due diligence, monitoring and incident planning to the same threat model evidence.

GDPR requires special attention because threat modeling and DPIA work should reinforce each other. The P17 Data Protection and Privacy Policy [P17] states:

“Threat modeling and Data Protection Impact Assessments (DPIAs) are mandatory for high-risk processing systems.”
From section “Policy Implementation Requirements”, policy clause 6.3.4.

For smaller teams, the P17S Data Protection and Privacy Policy - SME [P17S] states:

“Privacy by design and by default must be enforced in all new systems and services”
From section “Governance Requirements”, policy clause 5.3.1.

The result is a practical operating model: use the same data flow diagrams, trust boundaries and abuse cases for security risk, privacy risk, supplier review and regulatory evidence.

A 90-minute design-risk sprint for high-risk features

Threat modeling does not need to begin as a heavy programme. For a new payment API, onboarding workflow, AI-enabled feature, identity service, cloud migration or external integration, a 90-minute design-risk sprint can produce valuable evidence.

1. Open a project security checkpoint

Use P24 clause 6.1.1 as the trigger. For every new application or major change, create an evidence folder with:

• Architecture diagram
• Data flow diagram
• Trust boundary map
• Asset list
• Personal data notes
• Supplier and ICT dependency list
• Initial security requirements
• Threat model worksheet
• Risk register entries
• Mitigation and test traceability
• Approval record

For smaller organisations, P24S Secure Development Policy - SME [P24S] supports the same discipline by linking secure development processes to developer access control, testing, threat modeling and documentation. It also requires centralised retention of checklists, review approvals, testing reports and component inventories for audit purposes. Clause 11.3.1 references SA-3 to SA-15 to define secure development processes, including threat modeling.

2. Draw the minimum viable data flow

Do not start with a polished diagram. Start with the flows that create risk:

• User uploads identity documents or transaction data.
• Web application sends requests to the API.
• API writes to managed storage or a database.
• Supplier receives verification or analytics data.
• Internal analyst portal displays results.
• Customer system retrieves status or decisions.
• Logs, monitoring tools and backups receive copies.

Mark each trust boundary: internet to application, application to API, internal service to supplier, production system to analytics, administrator to privileged function and production to non-production environment.

3. Run STRIDE and abuse cases together

For each boundary, ask the STRIDE questions and write abuse cases in plain business language. The goal is not to list every imaginable attack. The goal is to identify plausible, material scenarios that affect confidentiality, integrity, availability, privacy, resilience or safety.

4. Convert findings into risk scenarios

Use the ZB Step 9 formula:

“[Threat] exploits [vulnerability] on [asset], resulting in [impact].”

For example:

“An attacker exploits weak object storage access controls on the identity document repository, resulting in unauthorised disclosure of personal data and regulatory notification exposure.”

Then add owner, likelihood, impact, inherent risk, treatment option, target control, residual risk and evidence.

5. Derive requirements and tests

A threat model is not finished when risks are listed. It is finished when mitigations are implemented, tested or formally accepted.

The Change Management Policy - SME gives a practical trigger:

“If a change involves sensitive data, system access rights, or external integrations, a security impact review is required. The designated security or compliance contact must assess whether the change introduces additional risks and recommend additional safeguards.”
From section “Risk Treatment and Exceptions”, policy clause 7.5.1.

Sensitive data, access rights and external integrations are exactly the changes that demand design-risk review.

What different auditors will ask

An ISO/IEC 27001:2022 auditor will ask whether threat modeling is part of a defined risk assessment process, whether criteria are consistent, whether risk owners approved residual risks, whether treatment plans link to the SoA and whether evidence is retained. They will look for repeatability, version history, management review visibility and internal audit coverage.

For Annex A, they will connect your evidence to 5.8, 8.25, 8.26, 8.27 and 8.29. ZB Step 21, Controls in Action, highlights secure system architecture and engineering principles by asking what principles guide secure architecture. Auditors may ask whether threat modeling is conducted during design using methods such as STRIDE or attack trees, and whether architectural decisions are reviewed before implementation.

A NIS2 reviewer will focus on governance and proportionality. They may ask whether management approved the cybersecurity risk-management approach, whether secure acquisition, development and maintenance are covered, whether supplier vulnerabilities are considered, whether incident scenarios link to reporting workflows and whether continuity scenarios are analysed. NIS2 Article 23 staged reporting for significant incidents, including early warning within 24 hours, notification within 72 hours and a final report within one month, makes scenario clarity especially valuable.

A DORA examiner will focus on ICT risk governance, critical functions, ICT assets, external dependencies, resilience testing and ICT third-party services. If the system supports a critical or important function, they will expect stronger evidence linking threat scenarios to asset inventories, dependency maps, testing plans, third-party contracts and recovery measures.

A privacy reviewer will inspect data flows and ask whether personal data processing is necessary, lawful, minimised and protected. They will ask whether special categories of data are involved, whether pseudonymisation or encryption is used, whether retention is justified and whether a DPIA is required. Threat modeling and DPIA are different activities, but they should share diagrams, scenarios and mitigations.

A NIST CSF or COBIT 2019 oriented reviewer will look for governance, process ownership, performance, accountability and continuous improvement. They may care less about the STRIDE worksheet itself and more about whether the process is reliable, measured, approved and improved.

Common threat modeling evidence failures

The most common failures are not technical. They are evidence failures.

Teams perform threat modeling too late, after the system is already built. At that point, the workshop becomes a pre-penetration-test briefing instead of a design control.

Findings are not converted into risk language. “Add auth” or “logging issue” may help engineers, but auditors need asset, threat, vulnerability, impact, owner, treatment and residual risk.

Privacy and security are separated. One team documents spoofing and injection risk while another documents retention and lawful basis. GDPR accountability works better when data flows, abuse cases and DPIA triggers are connected.

Supplier assumptions remain undocumented. NIS2, DORA and NIST CSF all raise expectations for ICT supply chain risk. If a mitigation depends on a supplier’s encryption, logging, deletion, resilience or incident response, collect the evidence.

Tests do not map back to threats. A penetration test report may be useful, but it may not prove that the specific design risks were mitigated. Each major threat finding should have validation evidence.

Residual risk acceptance is informal. “We accept this for MVP” is not enough. ISO/IEC 27001:2022 expects residual risk acceptance by appropriate risk owners as documented information.

Your 2026 threat modeling evidence pack

For every major system or significant change, keep a standard evidence pack that can support ISO 27001, NIS2, DORA, CRA, GDPR and customer assurance.

The Risk Management Policy - SME captures the operating model well:

“It ensures that risk management is an active component of planning, project execution, supplier selection, and incident response, in alignment with ISO 27001, ISO 31000, and applicable regulatory requirements.”
From section “Purpose”, policy clause 1.2.

That is the right target. Threat modeling should influence planning, engineering, supplier selection, incident response and audit readiness.

Make threat modeling audit-ready before your next release

The organisations that will handle 2026 compliance pressure best are not the ones with the most diagrams. They are the ones that can prove a simple chain:

Design risk was identified. Risk was assessed. Controls were selected. Mitigations were implemented. Tests validated the mitigations. Residual risk was approved. Evidence maps to the frameworks that matter.

Start with one high-risk change: a payment integration, new API, AI-enabled workflow, identity feature, cloud migration, customer-facing product release or supplier-connected service. Run a 90-minute design-risk sprint. Use ZB to convert findings into risk scenarios, treatment plans and SoA traceability. Use ZC to map ISO/IEC 27002:2022 controls such as 5.8, 8.25, 8.26, 8.27 and 8.29 to supporting controls, supplier risk, privacy, testing and audit evidence. Align P24, P06, P17, P24S and your change management procedure so threat modeling becomes required, repeatable and reviewable.

If you want Clarysec to help, start with a threat modeling evidence review. We will assess one real project, identify gaps against ISO/IEC 27001:2022, NIS2, DORA, CRA and GDPR expectations, and give you a practical remediation roadmap your engineers, auditors and board can all understand.