Risk assessment, threat modeling, security policy and controls
Learn how teams assess security risk, model threats, set policy, and select controls using a practical example.
## Four related terms, four jobs
A **risk assessment** identifies and analyzes risks to an organization, its operations, or its assets. It considers relevant threats and vulnerabilities and their potential consequences, so that decision makers can prioritize treatment. Depending on the method, likelihood and impact may be expressed qualitatively or quantitatively. A risk assessment informs a decision; it does not eliminate uncertainty. [NIST: risk assessment](https://csrc.nist.gov/glossary/term/risk_assessment).
**Threat modeling** is a structured way to identify and understand threats to a system, application, or other asset. Teams describe what they are protecting, how the system works, and how it might be attacked, then use the results to prioritize mitigations. Threat modeling can support a risk assessment, but mapping attack paths alone does not establish the organization’s overall risk. [NIST: threat modeling](https://csrc.nist.gov/glossary/term/threat_modeling).
A **security policy** states an organization’s security objectives, rules, or practices. It provides direction for decisions and behavior; the exact scope depends on the policy. A **security control** is a safeguard or countermeasure used to protect an information system or organization. Controls can be technical, operational, or management measures. A policy can require a control, but a policy and a control are different concepts. [NIST: security policy](https://csrc.nist.gov/glossary/term/security_policy); [NIST: security control](https://csrc.nist.gov/glossary/term/security_control).
## Example: a public application
Consider an application that stores customer documents. Its team maps the browser, API, identity provider, and storage service, then asks how an attacker might use a stolen session or excessive permissions to access documents. This is threat modeling: the diagram and attack scenarios make assumptions and trust boundaries visible.
The team assesses the potential impact of document disclosure and the likelihood of the scenarios using the evidence available, including access patterns and existing safeguards. It records uncertainty and compares the risk with other priorities. A policy might require access to customer documents to be restricted and reviewed. Controls might include authorization checks at the API, access logging, and periodic permission reviews. The team tests whether those controls operate as intended and documents any risk that remains after treatment.
## Attack surface and penetration testing
An attack surface is the set of points where an attacker could try to interact with a system, cause an effect, or extract data. For the example application, entry points can include a public sign-in page, API endpoints and accessible administrative interfaces. An entry point is not automatically a vulnerability, and an inventory may be incomplete. The [NIST attack surface definition](https://csrc.nist.gov/glossary/term/Attack_Surface) describes these points in terms of the boundary of a system or environment.
A penetration test is a constrained security assessment in which authorized assessors attempt to bypass selected security controls to identify exploitable weaknesses. It examines what can be demonstrated within an agreed scope and period; a test without findings is not proof that the entire system is secure. Before testing, establish the system owner's authorization and [rules of engagement](https://csrc.nist.gov/glossary/term/rules_of_engagement), including the allowed targets, methods, schedule, contacts and stop conditions. See also [NIST's penetration testing definitions](https://csrc.nist.gov/glossary/term/penetration_testing).
An owner might use an attack-surface inventory to define which application interfaces are in a planned test. Afterward, the team reviews the report, prioritizes fixes, verifies remediation and tracks remaining uncertainty. Mapping the surface, performing a test and assessing organizational risk are related activities with different purposes; none alone guarantees complete coverage. Sources reviewed on 2026-11-01.
## Keep the assessment current
Assign owners to treatment decisions and review the assessment when the application, its data, dependencies, or threat assumptions change. Monitor control operation and investigate exceptions. An inventory of controls is not proof that controls work, and neither an assessment nor a threat model guarantees that every attack has been found.