Who is accountable for keeping threat models current as systems evolve?

Why This Matters for Security Teams

Threat models are only useful when they reflect how a system actually operates today, not how it was designed last quarter. The teams changing code, infrastructure, prompts, integrations, and access paths are the ones creating new attack surface, so accountability has to follow the change. Security can define the method and challenge assumptions, but it cannot see every implementation detail without partner ownership. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that risk treatment depends on continuous control operation, not one-time design review.

When threat models drift, the usual failure is not a missing diagram. It is a stale set of assumptions about trust boundaries, privilege paths, external dependencies, and failure modes. That becomes especially risky in systems that now include AI services, non-human identities, API-driven automations, or rapidly changing cloud resources. In those environments, a model that is not updated with each material change gives decision-makers false confidence and weakens prioritisation of testing, monitoring, and mitigation. In practice, many security teams encounter model drift only after a production incident or audit gap has already exposed it, rather than through intentional change control.

How It Works in Practice

Current best practice is to make threat model upkeep part of the delivery workflow, not a separate security ceremony. Product and engineering teams should update the model whenever they introduce a new data flow, authentication path, third-party service, AI component, privileged integration, or significant infrastructure change. Security should set the template, define the review triggers, and verify that the most important attack paths are covered, but the system owners need to supply the operational detail.

A practical operating model usually includes:

• Change triggers tied to architecture changes, new secrets, new agents, new APIs, or new trust boundaries.
• Ownership mapped to the service or product team that can actually explain and remediate the risk.
• Scheduled reviews for high-risk systems, with event-driven updates when major releases land.
• Evidence that findings were triaged into backlog items, control changes, or monitoring rules.
• Integration with incident learnings so the model reflects what attackers are doing, not just what designers expected.

For emerging AI-enabled environments, threat modeling should also consider prompt injection, model poisoning, output abuse, and tool misuse. The MITRE ATLAS adversarial AI threat matrix is useful for mapping attacker behaviour against model and workflow weaknesses, while the CSA MAESTRO agentic AI threat modeling framework helps teams reason about autonomy, delegation, and tool execution. Where systems evolve quickly, teams should also watch current CISA cyber threat advisories so the model reflects active attacker behaviour, not just theoretical risks. These controls tend to break down when ownership is split across multiple vendors and no single team can update the architecture truthfully.

Common Variations and Edge Cases

Tighter threat model governance often increases delivery overhead, requiring organisations to balance speed against assurance. That tradeoff becomes sharper in microservices, platform engineering, and agentic AI environments where the system changes continuously and no single diagram stays accurate for long.

Best practice is evolving for products that rely on generated code, external models, or self-directed agents. There is no universal standard for how often these threat models must be refreshed, but the update cadence should be risk-based and tied to material change rather than calendar habit. A low-risk internal tool may only need updates at major release points, while a customer-facing AI workflow with secrets, tool access, and regulated data should be reviewed much more often.

The same applies where responsibilities are distributed across product, platform, and security teams. Shared accountability works only if one team is clearly named as the system owner and others have explicit review duties. Otherwise, model maintenance becomes a compliance artifact with no operational value. For teams managing high-impact controls, it is also sensible to align the model with the control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls and, where AI-enabled attack paths are relevant, keep the model anchored to adversarial techniques and observed campaigns such as the Anthropic first AI-orchestrated cyber espionage campaign report.

Related resources from NHI Mgmt Group

• Who should be accountable for keeping Singapore compliance procedures current?
• What does AI model abuse reveal about the current NHI threat surface?
• Who is accountable when contractor-held credentials expose cloud and internal systems?
• Why do agentic AI systems break segregation of duties models?