Not an audit
The confirmation CERT-In asks for is yours to make; the audit after it comes from an empanelled auditor. We are not one, and nothing here is an audit.
Threat modeling services in India
Find what could go wrong in your design — before you build it.
We study your system’s design, not the running system: how data moves, where trust changes hands, and what could go wrong, using a named method such as STRIDE or LINDDUN.
- The method named, with the reason
- A recorded response to every threat
- What the model leaves out, in writing
- CERT-In audit policy, section 8 item vii
- NIST SSDF v1.1, PW.1.1
- SP 800-53 SA-11(2)
- SEBI CSCRF
- RBI DPSC clause 22
In brief
- What it is
- A structured review of a system’s design, before you build or change it, to find what could go wrong.
- Why it matters
- A control nobody specified is a design flaw that better code alone cannot fix. CERT-In asks you to confirm secure design and development before any assessment starts.
- What you get
- A written threat model: a data flow diagram with trust boundaries, the method and why, a response to each threat, and its exclusions.
Why design comes first
Some flaws live in the design, not the code.
A control nobody specified is missing from the code and from the running system, which makes it a design finding, not an implementation one. OWASP's Top 10 (2025 edition) says under A06, Insecure Design: "An insecure design cannot be fixed by a perfect implementation as needed security controls were never created to defend against specific attacks." That is a category definition, not the standard we measure against.
In India, CERT-In (the Indian Computer Emergency Response Team) asks audited organizations to confirm their applications were designed and developed with secure practice before any assessment starts; threat modeling covers the design part. Its application security guidelines, addressed in section 2 to entities that develop or outsource applications (government-sector ones in particular), say in their introduction: "Relying solely on post-development audits for security is inadequate."
Where trust changes hands
The model starts from a data flow diagram (DFD). OWASP's Threat Modeling Cheat Sheet says it must give "a clear view of trust boundaries, data flows, data stores, processes, and the external entities which may interact with the system." In an ordering app, the order from a browser and the payment request to the payment provider both cross a trust boundary, and each crossing is a question the model must answer.
What CERT-In, NIST and OWASP SAMM say
CERT-In. Section 8 item vii of the audit policy itself points application owners to the application security guidelines quoted above. We cite the copy at cert-in.org.in/PDF/Application_Security_Guidelines.pdf.
NIST SSDF, SP 800-218 Version 1.1, February 2022. Practice PW.1 is "Design Software to Meet Security Requirements and Mitigate Security Risks". NIST's references for task PW.1.1 include, in its own labels: SP80053: SA-8, SA-11(2), SA-11(6), SA-15(5) · PCISSLC: 3.2, 3.3 · OWASPSAMM: TA1-A, TA1-B, TA3-B, DR1-A · ISO27034: 7.3.3 · MSSDL: 4 · IEC62443: SM-4, SR-1, SR-2, SD-1 · SCFPSSD: "Threat Modeling" · SCTTM: "Entire guide" · NISTCSF: ID.RA. NIST cites Microsoft's SDL as it then stood; Microsoft now lists ten practices, threat modeling third.
NIST SP 800-53 Rev. 5. Beside SA-11(2): SA-15(8) covers reusing threat and vulnerability information from similar systems; SA-8's discussion lists threat modeling among activities that identify attack vectors, design patterns and compensating controls.
NIST SP 800-154, Guide to Data-Centric System Threat Modeling, sections 3 and 4. Threat modeling is "a form of risk assessment that models aspects of the attack and defense sides of a particular logical entity", such as data, an application, a host, a system or an environment. Its four steps: characterize the system and data, select the attack vectors, characterize the controls that mitigate them, analyze the model. It is "not intended to replace existing methodologies". Cite it as a draft: NIST's CSRC page says NIST plans to finalize it.
OWASP SAMM. Threat Modeling is stream B of the Threat Assessment practice (stream A: Application Risk Profile) in the Design function, beside Security Requirements and Secure Architecture. SAMM's page, which has no version or date, names three maturity levels; we quote two: best-effort, risk-based threat modeling at level one, and standardized training, processes and tools organization-wide at level two. The TA codes above are NIST's labels. CERT-In's guidelines (section 3.2(b)) describe SAMM with four levels; we do not resolve the difference.
Choosing the method
A named method, picked for your system.
We agree the method at scoping and write the reason into the model. We have no house default.
| Method | Published by | Fits when |
|---|---|---|
| STRIDE | Microsoft | You care about the security of each component, checked element by element. |
| LINDDUN | DistriNet Research Unit, KU Leuven, first published in 2010 | Personal data is in scope. A privacy framework, positioned as STRIDE’s counterpart. |
| Attack trees | Bruce Schneier, Dr. Dobb's Journal, December 1999 | One stated goal needs breaking into the paths that reach it. |
| PASTA | Tony UcedaVélez and Marco M. Morana, Risk Centric Threat Modeling, Wiley, 2015 | You want a risk-centric method. |
What each method looks for
OWASP's Threat Modeling Cheat Sheet documents these unequally: STRIDE gets a full section with a prompt table, PASTA and OCTAVE one clause of body text, LINDDUN and VAST bare reference links, and attack trees no mention.
STRIDE, in Microsoft's terms: Spoofing (using another user's authentication information), Tampering (malicious changes to data), Repudiation (denying an action when nobody can prove otherwise), Information Disclosure, Denial of Service (to valid users) and Elevation of Privilege (an unprivileged user gaining privileged access). Microsoft applies it "STRIDE per Element" and calls it "Centered on Software" and "a focused design analysis technique".
LINDDUN has seven privacy threat types: Linking, Identifying, Non-repudiation, Detecting, Data Disclosure, Unawareness (paired with Unintervenability on its threat-types page) and Non-compliance. Three approaches: GO (lean, with a card deck), PRO (systematic, from data flow diagrams) and MAESTRO (from an enriched system description; "more info coming soon"). India's DPDP Rules, 2025 name no design-stage privacy analysis.
Attack trees put the goal at the root and the ways to reach it at the leaves, joined by AND and OR nodes; leaf values (possible or impossible, or a cost) roll up the tree. No standards body or version number stands behind it.
PASTA: we print no stage list; the ones in circulation come from vendor pages and secondary summaries, not the publisher.
How we work
Four questions, answered in five steps.
The Threat Modeling Manifesto asks: What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job? Steps 01 and 02 answer the first question, step 03 the second, step 04 the third and step 05 the fourth. We use the Manifesto's wording.
Agree the boundary, then draw it
Following CERT-In's guidelines (section 4.9), we identify "the boundaries of the application, including its components, data flows, and interfaces", then draw the diagram. Your team says where trust boundaries sit, and on whose authority.
Name the data and its objectives
Following NIST SP 800-154 section 4.1, we list the data that matters: where it is authorized to be stored, sent, used, entered and output; how it moves; what must be protected about it (its security objectives); and the people and processes authorized to access it in ways that could affect those objectives. If you want it to cover only one objective, we agree that at scoping.
Find threats by a named method
STRIDE, LINDDUN or attack trees, chosen for this system, with the reason written down.
Record a response to each threat
As task PW.1.2 of NIST's Secure Software Development Framework (SSDF) describes, we record each threat's response, how mitigations will work and why any exception was approved. You keep the record for audit and maintenance.
Check against criteria you set
SP 800-53 SA-11(2) leaves four choices to you, and the model answers each in writing: the context it used, the tools and methods, how broad and deep it went, and the acceptance criteria it had to meet.
Scope and limits
What this work does not do.
A design, not a live system
NIST separates threat modeling during design from threat modeling of systems already running. If yours already runs, tell us at scoping, because that changes the method.
AI systems are separate
Design analysis of an AI or model-driven system follows a different framework. It sits under AI security.
Who signs what. We write and sign the threat model, including its method statement and declared exclusions. Your architects and risk owners sign the design decisions, accepted mitigations and exceptions. A regulated entity keeps the practice in its own policies, as RBI's clause 22 asks; the model never states that a requirement is met. A later model, after a design change, is a separate project.
A secure design can still have implementation defects: secure code review looks for those. Want weaknesses in a running system fixed and verified? See vulnerability management. Big architecture decision? Security consulting. Security checks in your release pipeline? DevSecOps consulting. Compliance driver? See ISO 27001, PCI DSS compliance or GRC and compliance. See all defensive cybersecurity services.
A representation of the system (its design), not the running system. The Threat Modeling Manifesto defines it as "analyzing representations of a system to highlight concerns about security and privacy characteristics". NIST SP 800-154 (March 2016, still an Initial Public Draft) separates software threat modeling, during design, from system threat modeling of operational systems, which "tends to be largely informal and ad hoc". We do the first.
CERT-In puts design first, and asks you, not the auditor, to confirm it. Section 8 item vii of its Comprehensive Cyber Security Audit Policy Guidelines, Version 1.0, 25.07.2025: "Auditee organizations must confirm that applications are designed & developed with secure practice prior to commencing any assessment". Section 5.6 of its "Guidelines for Secure Application Design, Development, Implementation & Operations": an application developed without any secure design and development practices "should not be considered for assessment and audits". Booking the assessment first leaves the confirmation unmade.
No. NIST's SSDF task PW.1.1 lists three "forms of risk modeling" side by side: threat modeling, attack modeling and attack surface mapping. An attack surface assessment lists what can be reached on a live system; a threat model analyzes a design, before there is anything to reach. Want a live system's reachable surface? Say so at scoping: that is a different engagement.
We agree it at scoping, and the model names it with the reason: STRIDE for the security of components, LINDDUN when personal data is in scope, attack trees for breaking one stated goal into paths. The Threat Modeling Manifesto lists Hero Threat Modeler and Perfect Representation among its anti-patterns, so there is no house default.
NIST leaves that to you. SP 800-53 Rev. 5 control enhancement SA-11(2) has the developer perform threat modeling and vulnerability analyses, with four things organization-defined: information on impact, operating environment, known or assumed threats and acceptable risk levels; tools and methods; breadth and depth; and acceptance criteria. If you don't set them, the supplier does. Put these four questions to any supplier, us included. OWASP's Threat Modeling Cheat Sheet asks: "Has the threat model been formally documented?"
When the design changes, and the duty sits with whoever builds the system. SA-11(2)'s discussion warns that systems "may deviate significantly from the functional and design specifications", so the developer updates the analysis during development and before delivery. SSDF PW.1.2 says: "Track and maintain the software's security requirements, risks, and design decisions." A later model from us is a separate project.
SEBI's Cybersecurity and Cyber Resilience Framework, Version 1.0 (circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 August 2024, cited as the clauses stand there) names it for regulated entities (REs) at ID.AM guidelines item 4, which places threat modeling, based on risk assessment, between maintaining an asset inventory and conducting vulnerability assessment ("All REs (Mandatory)"); PR.IP.S4 and PR.IP.S6 (Secure Software Development Cycle), for threat modeling and application security testing during development ("All REs"); and EV.ST guidelines item 1, to anticipate new attack vectors ("All REs except small, self-certification REs"). RBI's Master Direction on Digital Payment Security Controls (RBI/2020-21/74, 18 February 2021) says at clause 22 (Chapter II, Application Security Life Cycle) that REs, including those partnering to co-brand or co-develop applications, "shall adopt and incorporate a threat modelling approach during application lifecycle management into their policies, processes, guidelines and procedures". Clause 20 asks for "secure by design". The direction is addressed to scheduled commercial banks (excluding regional rural banks), small finance banks, payments banks and credit-card issuing NBFCs.
Neither names it in the documents we read. No ISO/IEC 27002:2022 control title (the source of Annex A) contains the phrase, per the table of contents on ISO's Online Browsing Platform. An auditor would expect the evidence under the development controls, 8.25 to 8.31; their guidance is paywalled and unread, so we describe none of it. "Threat model" is absent from PCI DSS v4.0 SAQ D for Merchants, April 2022, which covers one merchant profile, not the whole standard. SSDF PW.1.1 cross-references PCI's Secure SLC Standard at 3.2 and 3.3 (behind a click-through gate), which PCI says is for "Software vendors that develop software that is commonly deployed in a payment environment." Mixing up the two PCI standards is the most common mistake here.
Let's talk
Tell us what stage your system is at.
Send the architecture material you have, or a regulator’s clause number. Delivered remotely from India. We reply within one working day.