Product Risk Assessment Procedure Template

Template draft. Replace everything in [square brackets] with your own decision, delete what does not describe what you really do, and approve it through your own document control. It is not legal advice and does not make an organisation compliant or certified.

1. Purpose

This procedure gives product teams a repeatable way to find the security risks in a product before and after release, rate them on a common scale, and decide what to do about each. It brings together threat modelling, resilience planning and configuration control so that a product's risk is understood as a whole and recorded in the risk register.

2. Objective

Identify threats to confidentiality, integrity and availability for every product and major change, using STRIDE as a prompt for completeness.
Rate each risk consistently so that decisions are comparable across products.
Match each threat with controls that are specific, owned and tested.
Show the product can recover from disruption within agreed targets.
Give management a current view of residual product risk.

3. Scope

In scope: every product, platform, application, API, mobile app, embedded component and managed service that the Organisation builds, operates or resells, across its lifecycle from concept to retirement, including its hosting, supporting infrastructure, data stores, third-party components and operational processes.
In scope events: new products, major releases, changes to architecture or data flows, new integrations, new hosting, a significant incident, and a scheduled review at least every [12 months] for Critical and High products.
In scope people: product owners, architects, engineers, operations, security reviewers and suppliers that run parts of the product.
Out of scope: enterprise-wide risk assessment, which follows the Risk Management Policy, and individual vulnerability handling, which follows the Vulnerability Assessment and Penetration Testing Procedure.

4. Terms and Definitions

Term	Meaning
Asset	Anything of value in the product: data, services, credentials, code, hardware and reputation.
Threat	A potential cause of harm to an asset.
Trust boundary	A line in the architecture where data crosses between zones of different trust, such as internet to application or application to database.
STRIDE	A set of six threat categories: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.
Inherent risk	Risk before controls.
Residual risk	Risk remaining after controls.
Recovery time objective (RTO)	The longest time the product may be unavailable.
Recovery point objective (RPO)	The longest period of data loss that is acceptable.

5. Roles and Responsibilities

Role	Responsibilities
Document owner (Head of Product Security)	Maintains the method and worksheet, facilitates assessments of Critical products and reports to management.
Product owner	Owns the product risk, joins assessments, funds treatments and accepts residual risk within authority.
Solution architect	Supplies diagrams and data flows, and designs controls.
Engineering and operations	Implement and run controls, supply evidence and fix gaps.
Information security team	Challenges the assessment, checks controls, and records risks in the register.
Senior management	Accepts residual risk rated High or Critical.

Activity	Responsible	Accountable	Consulted	Informed
Prepare product description and data flow diagram	Solution architect	Product owner	Engineering and operations	Information security team
Run STRIDE threat modelling workshop	Head of Product Security	Product owner	Solution architect; Engineering and operations	Senior management
Rate risks and select treatments	Product owner	Head of Product Security	Information security team	Senior management
Implement controls	Engineering and operations	Product owner	Information security team	Head of Product Security
Test recovery and DR site	Engineering and operations	Head of IT	Product owner	Head of Product Security
Accept residual risk	Product owner	Senior management	Head of Product Security	Information security team

6. Assessment Method

DescribeThe solution architect produces a one-page product description, an architecture diagram with trust boundaries, and a data flow diagram that shows each type of data and where it is stored. Target: [3 working days].
List assets and impactRecord the assets and the harm from losing confidentiality, integrity or availability (financial, legal, customer, operational).
Find threatsWalk each data flow and trust boundary with the STRIDE categories below and log each threat in the worksheet (Annexure A).
RateScore likelihood and impact from 1 to 5; risk equals likelihood times impact.
TreatFor each risk choose reduce, avoid, transfer or accept; assign a control, owner and date.
ReviewThe information security team checks the worksheet; residual risk is accepted per the table below; entries go into the risk register.
Follow upTrack treatments to closure and rerun the assessment on a trigger or at the scheduled interval.

Score	Rating	Decision authority	Action
20 to 25	Critical	Senior management	Do not release until reduced; weekly review
12 to 19	High	Senior management	Treatment plan within [30 days]
6 to 11	Medium	Product owner with Head of Product Security	Treatment plan within [90 days]
1 to 5	Low	Product owner	Accept and monitor

7. Threat Modelling Using STRIDE

The tables below give common threats and controls for each category. Teams add threats specific to their product. A control is only counted when it is implemented and has evidence.

7.1 Spoofing

Threats	Controls	Evidence
Stolen or guessed credentials used to impersonate a user	Multi-factor authentication, password policy, account lockout, breached-password checks	Authentication configuration; test results
Fake service or device presenting itself as genuine	Mutual TLS, certificate validation, signed requests, device registration	Certificate inventory; penetration test
Session hijacking	Short-lived tokens, secure cookie flags, token binding, rotation on privilege change	Code review; scan result
Phishing of administrators	Phishing-resistant authentication for admins, awareness training	Training records; sign-in logs

7.2 Tampering

Threats	Controls	Evidence
Modification of data in transit	TLS everywhere, message signing for sensitive messages	TLS scan
Altered data at rest or in the database	Database access control, integrity checks, write audit trails, immutable backups	Audit logs; integrity job output
Tampered code or build artefacts	Signed commits and builds, protected pipelines, software bill of materials	Pipeline configuration; signature checks
Changed configuration	Configuration as code, drift detection, change control	Drift reports
Manipulated input to alter logic	Server-side validation, parameterised queries	Code review; dynamic scan

7.3 Repudiation

Threats	Controls	Evidence
User denies performing a transaction	Unique identities, time-stamped audit trails, signed or confirmed transactions	Audit log sample
Administrator actions untraceable	Named admin accounts, session recording, no shared accounts	Privileged access reports
Logs altered or deleted	Central write-once log storage, restricted log access, clock synchronisation	Log platform configuration
Missing logs in integration steps	Log standards for every service, correlation identifiers	Log review

7.4 Information disclosure

Threats	Controls	Evidence
Exposure of data in storage	Encryption at rest, key separation per the Key Management Process, access by role	Storage configuration
Leakage through error messages, logs or backups	Generic errors, log scrubbing, encrypted backups	Code review; log samples
Over-broad API responses	Field-level filtering, authorisation on each object	API test
Misconfigured cloud storage or services	Default private, configuration scanning, review of public exposure	Cloud configuration scan
Insider or supplier misuse	Least privilege, data loss prevention, monitoring, contracts	Access reviews; supplier assessments

7.5 Denial of service

Threats	Controls	Evidence
Volumetric attack on public endpoints	Network-level protection and traffic scrubbing, content delivery network, rate limits	Load and resilience test
Resource exhaustion by a single user or bug	Quotas, timeouts, request size limits, queue back-pressure	Performance test
Single point of failure	Redundant components across zones, health checks, automatic failover	Architecture review; failover test
Dependency outage	Circuit breakers, graceful degradation, supplier SLAs	Dependency map
Account lockout abuse	Progressive delays and monitored lockouts	Authentication test

7.6 Elevation of privilege

Threats	Controls	Evidence
Broken access control, user reaches admin functions	Server-side role checks, deny by default, automated authorisation tests	Test suite results
Injection leading to code execution	Input validation, parameterised queries, least-privilege service accounts	Static and dynamic scans
Vulnerable or outdated components	Software composition scanning, patch timelines, pinned versions	Dependency report
Container or host escape	Hardened images, non-root processes, runtime policies	Image scan; configuration check
Standing privileged access	Just-in-time access, approval and logging, quarterly recertification	Privileged access logs

8. Disaster Recovery Site Availability

Each Critical and High product must be able to resume at an alternate site or region within its recovery objectives. The product owner states the targets, and the Head of IT confirms the design delivers them.

Product tier	RTO	RPO	DR design	Test frequency
Critical	[2 hours]	[15 minutes]	Active-active or warm standby in a separate region or site	[Twice yearly] with failover
High	[8 hours]	[1 hour]	Warm standby or rapid rebuild from code and replicated data	[Annually] with failover
Medium	[24 hours]	[24 hours]	Rebuild from backups	[Annually] restore test
Low	[72 hours]	[24 hours]	Restore when capacity allows	On change

The DR site or region is geographically separate enough not to share the same power, flood or network risk, and holds the same security controls as production.
DR runbooks list who fails over, in which order, how to verify and how to fail back; they are stored where they can be read during an outage of the primary site.
Replication links, access to the DR site and keys needed for decryption are tested at each exercise, and the results (actual RTO and RPO) are compared with targets.
Gaps found in a test become treatments in the worksheet with an owner and date within [30 days]. Further detail is in the BCP and DR Procedure.

9. Additional Controls

Control	Requirement	Reference
Security awareness training	Product, support and operations staff complete role-based training at joining and every [12 months], including secure development for engineers and phishing awareness.	HR Security Procedure
Incident response plan	Each product has an incident playbook with contacts, severity, containment steps and customer notification; exercised at least [annually].	Incident Management Procedure
Backup and recovery	Data is backed up at the frequency the RPO needs, encrypted, kept offsite and restored in tests at least [every 6 months].	Backup Management and Retention Procedure
Vendor risk management	Third-party components and services used by the product are assessed and monitored by tier.	Supplier Relationship Management Procedure
Data loss prevention	Rules detect and block bulk export or unauthorised sharing of Confidential and Restricted data from the product and its operators' endpoints.	Information Classification and Handling Policy
Monitoring	Security-relevant events are logged and alerts are triaged within [1 hour] for Critical products.	Logging and Monitoring Procedure

10. Secure Configuration Management

A product is only as secure as its settings. Configuration is defined, approved, deployed and checked as code wherever possible.

BaselineEngineering defines a hardened baseline for each platform, image and service, based on the Secure Configuration Policy and recognised hardening guidance, and the Head of Product Security approves it.
BuildConfiguration is stored in version control and applied by the pipeline; manual changes to production are prohibited except through break-glass access that is logged.
VerifyAutomated scans compare running systems with the baseline at least [daily] and report drift to the product owner.
FixDeviations are corrected within [7 days] or recorded as an exception with expiry; changes follow the Change Management Procedure.
ReviewBaselines are reviewed [annually], after incidents, and when vendors release new guidance.

Setting	Required state
Default and vendor accounts	Removed or disabled; passwords changed
Network services and ports	Only those required are open; management interfaces are not public
Encryption	Current protocol versions only; weak ciphers disabled
Logging	Enabled, forwarded and time-synchronised
Error output and debug modes	Disabled in production
Cloud storage and databases	Private by default; access through roles
Secrets	In the secrets vault, rotated on schedule
Patching	Current within the timelines of the Patch Management Procedure

11. Measures

Measure	Target	How it is measured
Critical and High products assessed in the last [12 months]	[100 percent]	Assessment register
Treatments completed by due date	[90 percent]	Risk register
Products with a tested DR plan in the last [12 months]	[100 percent] of Critical and High	DR test records
Actual recovery time within target in last test	[100 percent]	Test report
Configuration drift items open after [7 days]	[0]	Configuration scanner
Residual High and Critical risks without senior approval	[0]	Register review

12. Records and Evidence

Record	Kept by	Location	Retention
Completed worksheets and diagrams	Head of Product Security	Document management system	Life of product plus [3 years]
Risk register entries and approvals	Information security team	Risk register	Life of risk plus [3 years]
DR test reports	Engineering and operations	Document management system	[3 years]
Configuration baselines and drift reports	Engineering and operations	Version control and scanner	[2 years]

Annexure A: Product risk worksheet

Ref	Asset or flow	STRIDE category	Threat
PR-001	[Login flow]	Spoofing	[Credential stuffing]

Annexure B: Product description sheet

Field	Entry
Product name, version and owner
Purpose and users
Data types and highest classification
Hosting and regions
Third-party components and suppliers
Interfaces and trust boundaries
RTO and RPO
Diagram references
Assessment date and next review

Annexure C: Residual risk acceptance

Field	Entry
Risk reference and rating
Reason for not reducing further
Compensating controls
Review date
Accepted by (name, role) and date

13. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

14. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

15. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 27001:2022 references

Reference	Title
A.5.8	Information security in project management
A.8.9	Configuration management
A.8.25	Secure development life cycle
A.8.27	Secure system architecture and engineering principles
A.5.30	ICT readiness for business continuity
6.1.2	Information security risk assessment
6.1.3	Information security risk treatment