Threat Modelling for Product Managers: Change the Scope Before It Ships

Security reviews often happen after the product has made its most expensive promises: anyone can share it, access is instant, links never expire, and no recipient needs an account.

At that point, the security conversation sounds like obstruction because the feature’s shape has hardened.

Threat modelling is more useful earlier. It gives product managers a way to ask what could go wrong while changing the scope is still cheaper than defending it.

It is not a request for the PM to become a penetration tester. The PM’s contribution is to make assets, actors, product promises and acceptable risk explicit.

The OWASP framing is refreshingly plain: what are we working on, what can go wrong, what will we do about it, and did we do a good enough job?

A small flow is enough to begin

Imagine a reporting product for distributed teams. A proposed feature lets an analyst create a public link to a report and send it to an external partner.

The product brief says:

• no account required;
• link opens the live report;
• recipients can export the underlying rows;
• link remains valid until its creator revokes it;
• the page may include an AI-generated summary.

This is fictional. No incident or result is being claimed. It is useful because the commercial appeal and the security tension are both easy to see.

Do not model the entire platform. Set a boundary: creation of the link, delivery to a recipient, viewing, export, revocation and logging.

That boundary keeps the session tied to a decision. Wider platform risks can be recorded separately with an owner.

Put the flow on one page

Draw the fewest components needed to explain data movement:

analyst → authenticated product → link service → public viewer → export service

Add the report store, identity service, audit log and AI summary provider if the flow touches them.

Then mark trust boundaries. A browser crossing from an authenticated workspace to a public page is one. Sending report content to an external model provider may be another.

A trust boundary is not automatically a defect. It is a place where assumptions about identity, control or data handling change.

This makes threat modelling a natural partner to system design. The system view explains behaviour; the threat model challenges hostile or accidental use.

Name the assets before the attackers

Teams often start with dramatic attacker stories. Start with what requires protection instead.

For the report-sharing flow, the assets might be:

• report contents and exported rows;
• membership and customer identity;
• the creator’s sharing intent;
• link validity and revocation state;
• audit evidence;
• model inputs and generated summaries;
• trust in reports as unaltered records.

Assets include decisions and properties, not just databases. “Only the intended partner can view this report” is a property worth protecting.

Now name actors by capability and relationship:

• authorised analyst;
• intended external recipient;
• unintended person who receives a forwarded link;
• former employee retaining a link;
• automated scraper;
• malicious workspace member;
• compromised email or browser session;
• external processor used for the summary.

Avoid cartoon villains. A well-meaning recipient forwarding a link can create the same disclosure as a deliberate attacker.

Write abuse paths as stories with consequences

An abuse path connects an actor, an action, a weakness and harm. It should be concrete enough to affect design.

For example:

A recipient forwards the bearer link to a wider mailing list. Anyone with the URL can view and export current report data. The creator cannot see who accessed it.

Another:

A scraper discovers a link in browser history, chat logs or analytics referrer data and repeatedly exports rows until the link is manually revoked.

And one involving the summary:

Report content includes text intended to manipulate the summarisation prompt. The generated summary becomes misleading, while the interface presents it as authoritative.

The third path may not disclose data, but it threatens report integrity. AI governance should cover the model-specific controls in more depth.

Do not fill a page with every imaginable threat. Prioritise paths that are plausible, harmful and changeable by the current product decision.

Use consequences, not theatrical scores

A numerical risk score can create an illusion of measurement. Early discovery rarely supports precise probabilities.

For each path, discuss:

• the harm to an individual, customer or service;
• how many people or records could be affected;
• how easy the path is to repeat;
• what access or knowledge the actor needs;
• whether the harm is detectable and reversible;
• which assumption is least certain.

Labels such as low, medium and high can help route decisions if the organisation defines them. Preserve the reasoning beside the label.

A “high” with no account of harm is less useful than a plain explanation of who loses control of which data and why recovery would be difficult.

The model should change the product

The first proposal treats possession of a permanent URL as sufficient authorisation. That is convenient and difficult to contain.

The team compares mitigations against the product need, not against the original feature wording.

The need is: let an analyst share a current report with an external partner without a long onboarding process.

That does not require permanent, anonymous, exportable access.

The team narrows the hypothetical scope:

1. The creator must name a recipient email address.
2. The recipient receives a short-lived verification code.
3. Access expires after seven days by default, with a shorter option.
4. Export is off by default and requires a separate creator choice.
5. The creator can see access events and revoke the share immediately.
6. Public viewer pages omit third-party analytics, apply a restrictive referrer policy and are tested for unexpected network requests.
7. AI summaries are excluded from the first release pending a separate model-risk review.

This is a product decision, not merely a security control list. It changes friction, scope, interface copy, support work, telemetry and the promise made to customers.

The team has not “solved security”. It has removed the most permissive assumptions while preserving a bounded sharing task.

Match each mitigation to an abuse path

Controls earn their place by weakening a specific path.

Recipient verification reduces casual forwarding risk, but it does not protect a compromised inbox. Expiry limits exposure duration, but it does not stop a recipient copying data while access is valid.

Audit events improve detection and investigation. They do not prevent disclosure. Disabling export makes bulk extraction harder, but screenshots and manual copying remain possible.

Writing these limits next to each mitigation prevents “defence in depth” from becoming a pile of unexplained features.

The OWASP Threat Modeling Cheat Sheet recommends connecting threats to mitigations and validating the work.

Validation can include design review, automated tests, access-control tests, misuse cases, log inspection and targeted security testing. The method should fit the path.

Record residual risk with an owner

After the narrower release, one residual risk is clear: a verified recipient can intentionally copy or photograph information while authorised.

The product cannot guarantee control after legitimate display. Pretending otherwise would be a dishonest promise.

The team records:

• Residual risk: authorised recipients can reproduce viewed information.
• Current reduction: explicit recipient, expiry, export default off, visible sharing notice and access log.
• Owner: product lead for external sharing, with security sign-off.
• Review trigger: customer demand for sensitive report classes, access anomalies or a request for longer expiry.
• Decision: proceed only for reports not marked restricted; restricted reports remain unshareable externally.

The owner is not personally liable for every attack. Ownership means keeping the decision, evidence and review trigger alive.

If the remaining risk exceeds the organisation’s tolerance, the answer is not a prettier warning. The feature should stop or change again.

Bring the right people, briefly

Keep the session bounded by arriving with the flow and scope already drafted.

Include product, engineering, design and someone accountable for security. Add privacy, data or operations expertise when the assets require it.

Use the first part to correct the diagram. Use the second to identify assets, actors and paths. Use the final part to change scope and assign unresolved work.

Do not spend the meeting debating a comprehensive taxonomy. OWASP offers methods and resources when a team needs a formal approach, but the output still has to inform a decision.

The OWASP Threat Modeling project also treats threat modelling as a structured, repeatable activity rather than a one-off security gate.

Questions a PM should keep asking

During discovery:

• Which product promise creates the largest new exposure?
• What is the smallest flow we can model before committing to it?
• Which people, data and decision properties are assets?
• Where does trust change?
• Which misuse remains possible even when the system works as designed?

During shaping:

• Can we meet the need with less access, data, duration or automation?
• Which mitigation changes the experience?
• What operational capability does the control require?
• What evidence will show the control works?
• What failure would stop release?

Before release:

• Is every important path mitigated, accepted or removed by scope?
• Who owns each residual risk?
• Are logs useful without collecting unnecessary sensitive data?
• Do support and incident teams know the new flow?
• Which assumption should trigger a new model?

Those questions connect modelling to release management. A control that nobody can operate is not finished.

Know when to reopen the model

The diagram is not a museum piece. Revisit it when an asset, actor, boundary or product promise changes.

For this feature, triggers include allowing domains rather than named recipients, enabling export by default, extending expiry, adding comments or sending report data to a new AI provider.

A reported abuse pattern is another trigger, but teams should not wait for harm before revisiting a changed flow.

Threat modelling works best as a product design habit: small enough to repeat, specific enough to test, and early enough to make a safer option commercially possible.

It also sharpens ethical product decisions. Ethics asks what the product ought to permit; threat modelling tests how those intentions can fail.

The best output is not a long threat register. It is a better-shaped feature, a short account of what remains dangerous, and a named person who knows when the decision must be reopened.

Sources

• OWASP Threat Modeling
• OWASP Threat Modeling project
• OWASP Threat Modeling Cheat Sheet

Read next

• From Theory to Practice: System Design
• Ethics and Responsibility in Product Management
• Practical AI: AI Governance for Product Teams
• Lessons Learned in Release Management