Sekit CSF · Application Security · Policy
RCF-0118Threat modeling
The company formally identifies and documents potential threats to applications before development begins
Mapping at a glance
RCF-0118Threat modelingApplication Security · Policy
RCF-0118 maps to 7 controls across the published frameworks. +2 more in the table below. Open in the full graph →
Maps to ISO/IEC 27001:2022
Curated mapping with the reasoning, not just the codes.
A.8.25Secure development life cyclesupportsThe threat-modeling policy facet requires threats to be documented before development starts on new applications and major changes, an early-lifecycle piece of A.8.25.A.8.26Application security requirementssupportsThe threat-modeling policy facet requires threats to be documented for new applications before development starts, feeding directly into the requirements A.8.26 asks organizations to define.A.8.27Secure system architecture and engineering principlessupportsThe threat-modeling policy facet requires documented threats before development starts on new systems and major changes, an entry point into the secure engineering discipline A.8.27 asks for.
Maps to NIST CSF 2.0
Curated mapping with the reasoning, not just the codes.
ID.RA-01Vulnerabilities identified and recordedID.RA-03Threats identified and recordedPR.PS-01Configuration management applied
Maps to ISO/IEC 42001:2023 — Annex A
Curated mapping with the reasoning, not just the codes.
Evidence that proves this control
What an auditor, or Sekit's evidence engine, asks for.
Secure development policy
The rules the development team follows to build software securely: security requirements, code review and threat modeling.
From the Sekit evidence catalog
This topic through the other lenses
All Application Security controls
Ask Sekura: “What evidence proves RCF-0118?”
Also via MCP, free with account