Skip to main content
โ† All controls
RA-3 / SA-11 / CM-4 NIST SP 800-53 Rev 5

Threat modelling for high-risk changes

Demonstrate that all high-risk changes undergo documented threat modelling before production deployment, with identified threats tracked to remediation or documented acceptance.

Description

What this control does

Threat modelling for high-risk changes requires organizations to conduct structured threat analysis before deploying architectural modifications, new externally-facing services, privileged access expansions, or changes to authentication/authorization mechanisms. The process applies frameworks such as STRIDE, PASTA, or attack trees to identify attack vectors, assess exploitability, and determine countermeasures prior to production release. This control prevents the introduction of exploitable vulnerabilities into production environments by embedding security analysis into change approval workflows for changes classified as high-risk based on data sensitivity, external exposure, or privilege level.

Control objective

What auditing this proves

Demonstrate that all high-risk changes undergo documented threat modelling before production deployment, with identified threats tracked to remediation or documented acceptance.

Associated risks

Risks this control addresses

  • Privilege escalation vulnerabilities introduced through unreviewed access control changes in new application features
  • Data exfiltration pathways created by new API endpoints lacking input validation or authentication controls
  • Lateral movement opportunities arising from new service-to-service trust relationships without network segmentation
  • Authentication bypass flaws resulting from changes to identity federation or SSO configurations
  • Injection attacks enabled by database schema changes that bypass existing parameterization controls
  • Denial-of-service exposure from new external interfaces lacking rate limiting or resource quotas
  • Compliance violations when changes to data processing flows are deployed without privacy impact assessment

Testing procedure

How an auditor verifies this control

  1. Obtain the change management policy and identify criteria that trigger mandatory threat modelling (e.g., architectural changes, new external services, privilege modifications).
  2. Retrieve the complete list of production changes classified as high-risk over the audit period from the change management system.
  3. Select a representative sample of 8-12 high-risk changes spanning different change categories and business units.
  4. For each sampled change, request threat model documentation including identified threats, attack scenarios, STRIDE classification or equivalent, and assigned risk ratings.
  5. Verify that threat modelling occurred before change approval by comparing threat model timestamps to change request approval dates and deployment dates.
  6. Review evidence that identified threats resulted in either security control implementation, architectural modification, or documented risk acceptance with appropriate authority sign-off.
  7. Interview three threat model authors to confirm methodology consistency, tool usage, and integration with change approval gates.
  8. Test one completed high-risk change by conducting an independent mini threat model exercise and comparing findings to the submitted threat model to assess adequacy and rigor.
Evidence required Change management records with high-risk classification flags and approval workflows; threat model documents containing threat enumeration, attack trees or data flow diagrams, STRIDE analysis tables, and remediation tracking; change request tickets showing threat model attachment or reference prior to approval date; risk acceptance forms with CISO or equivalent signature for unremediated threats; interview notes from threat modelling practitioners describing process and tooling.
Pass criteria All sampled high-risk changes have documented threat models completed before approval, identified threats are mapped to implemented controls or formally accepted risks, and the independent validation exercise confirms threat model adequacy.

Where this control is tested

Audit programs including this control