Threat Assessment Template
1. Document Information
| Field | Details |
|---|---|
| Organization | [Organization Name] |
| Threat Assessment ID | [TA-YYYY-XXX] |
| Assessment Date | [Date] |
| Assessment Type | New Threat / Threat Intelligence / Incident / Vulnerability / Periodic Review |
| Assessor | [Name / Role] |
| Security Owner | [Name / Role] |
| Related Risk ID | [R-XXX] |
| Related Vulnerability ID | [VUL-XXX] |
| Status | Draft / Under Review / Approved / Closed |
| Next Review Date | [Date] |
2. Purpose
The Threat Assessment Template is used to identify, analyse, and evaluate a specific information security threat and determine its potential relevance to the organization.
The assessment helps answer:
- What is the threat?
- Who or what could cause it?
- What assets could be targeted?
- How could the attack occur?
- What weaknesses could be exploited?
- How likely is the threat to affect the organization?
- What could be the impact?
- What controls already exist?
- What additional action may be required?
The output of the assessment may feed into the Security Risk Assessment, Risk Register, Vulnerability Management, Incident Management, or Security Improvement Plan.
3. Threat Identification
Threat Name
[Name of threat]
Threat Category
Select one or more:
- ☐ Malware
- ☐ Ransomware
- ☐ Phishing
- ☐ Credential Theft
- ☐ Account Takeover
- ☐ Insider Threat
- ☐ Web Application Attack
- ☐ API Attack
- ☐ Cloud Security Threat
- ☐ Denial of Service
- ☐ Data Exfiltration
- ☐ Supply Chain Attack
- ☐ Social Engineering
- ☐ Vulnerability Exploitation
- ☐ Physical Threat
- ☐ Fraud
- ☐ Third-Party Threat
- ☐ Other: [Specify]
Threat Description
Describe the threat in clear and concise terms.
Example:
Attackers may attempt to compromise privileged cloud credentials through phishing, credential theft, or session hijacking and use the compromised credentials to access production resources.
4. Threat Source / Threat Actor
Identify the potential source of the threat where reasonably known.
| Attribute | Details |
|---|---|
| Threat Actor | [Known / Unknown] |
| Actor Type | External / Internal / Third Party |
| Motivation | Financial / Espionage / Disruption / Fraud / Other |
| Capability | Low / Medium / High / Unknown |
| Target | Organization / Industry / Technology |
| Known Campaign | Yes / No / Unknown |
| Geographic Relevance | [If known] |
Possible threat actors include:
- Cybercriminals
- Hacktivists
- Nation-state actors
- Insiders
- Competitors
- Fraudsters
- Opportunistic attackers
- Compromised third parties
- Automated attack systems
Do not assign a specific threat actor without reasonable evidence.
5. Threat Intelligence Source
Record where the threat information came from.
| Field | Details |
|---|---|
| Source | [Security vendor / Government advisory / Internal monitoring / etc.] |
| Source URL / Reference | [Reference] |
| Date Published | [Date] |
| Date Received | [Date] |
| Source Reliability | High / Medium / Low / Unknown |
| Information Confidence | High / Medium / Low |
| Supporting Sources | [References] |
Where the information is based on external intelligence, the source should be validated where appropriate.
6. Threat Characteristics
Document the characteristics of the threat.
Attack Method
[Describe how the threat could operate.]
Attack Vector
Examples:
- Internet
- Web application
- API
- Cloud account
- Endpoint
- Supplier
- Physical access
- Remote access
- Software dependency
Attack Technique
[Describe the relevant technique.]
Where useful, the organization may map the technique to a recognized framework such as MITRE ATT&CK.
Required Conditions
Identify what must exist for the threat to succeed.
Examples:
- Compromised credentials
- Vulnerable software
- Internet exposure
- Misconfiguration
- Lack of MFA
- Excessive privileges
- Social engineering
- Supplier compromise
7. Threat Scenario
Describe the threat as a realistic scenario.
Example
An attacker sends a targeted phishing email to an employee with privileged AWS access. The attacker obtains the employee’s credentials and attempts to authenticate to the organization’s cloud environment. If MFA or other access controls are bypassed, the attacker may gain unauthorized access to production resources.
A good threat scenario should identify:
Threat Actor → Attack Vector → Weakness → Attack → Target → Potential Consequence
8. Affected Assets
Identify assets that could potentially be affected.
| Asset | Type | Criticality | Internet Exposed? | Data / Function |
|---|---|---|---|---|
| AWS Production | Cloud | Critical | Yes | SaaS platform |
| Customer Database | Data | Critical | Restricted | Customer information |
| Employee Laptop | Endpoint | Medium | Yes | Corporate access |
| Source Code Repository | Application | High | Restricted | Source code |
9. Affected Information
Identify information that could be affected.
- ☐ Customer data
- ☐ Personal data
- ☐ Financial information
- ☐ Authentication credentials
- ☐ Source code
- ☐ Intellectual property
- ☐ Employee information
- ☐ Confidential business information
- ☐ Security information
- ☐ Operational information
- ☐ Other: [Specify]
10. Threat Impact Analysis
Assess the potential consequences if the threat succeeds.
Confidentiality
Could unauthorized persons obtain information?
Impact: Low / Medium / High / Critical
Integrity
Could information or systems be modified or corrupted?
Impact: Low / Medium / High / Critical
Availability
Could systems or services become unavailable?
Impact: Low / Medium / High / Critical
Privacy
Could personal information be exposed or misused?
Impact: Low / Medium / High / Critical
Business Impact
Could the threat affect:
- Customer service
- Revenue
- Operations
- Regulatory obligations
- Contracts
- Business continuity
- Reputation
Overall Potential Impact: Low / Medium / High / Critical
11. Threat Likelihood
Assess the likelihood of the threat affecting the organization.
Consider:
- Threat activity
- Targeting of the industry
- Exposure of the organization
- Attack complexity
- Availability of exploit tools
- Existing controls
- Historical incidents
- Threat intelligence
- Vulnerability status
- Attacker capability
Example scale:
| Score | Likelihood | Description |
|---|---|---|
| 1 | Rare | Very unlikely under current conditions |
| 2 | Unlikely | Possible but not expected |
| 3 | Possible | Reasonably possible |
| 4 | Likely | Significant possibility |
| 5 | Almost Certain | Highly probable / actively occurring |
Likelihood Score
[1–5]
Reasoning
[Explain why the selected score was assigned.]
12. Threat Severity
A simple threat severity classification may be used:
| Severity | Description |
|---|---|
| Critical | Threat could cause severe impact and credible/existing exposure |
| High | Significant potential impact and realistic attack scenario |
| Medium | Relevant threat with moderate potential impact |
| Low | Limited potential impact or low relevance |
Threat Severity
[Critical / High / Medium / Low]
Justification
[Reason]
13. Existing Security Controls
Identify controls that currently reduce the likelihood or impact of the threat.
| Control | Type | Status | Evidence |
|---|---|---|---|
| MFA | Preventive | Implemented | IAM configuration |
| Least Privilege | Preventive | Implemented | Access review |
| EDR | Detective | Implemented | EDR console |
| Security Awareness | Preventive | Implemented | Training records |
| Cloud Logging | Detective | Implemented | CloudTrail |
| Incident Response | Corrective | Implemented | IR Procedure |
Controls should be assessed for actual operation rather than simply being listed because a policy exists.
14. Control Effectiveness
Assess the effectiveness of existing controls.
| Control | Effectiveness | Comments |
|---|---|---|
| MFA | Effective | Enforced for privileged users |
| Access Reviews | Partially Effective | Quarterly review required |
| Security Awareness | Effective | Training completed |
| Monitoring | Effective | Alerts configured |
| Incident Response | Partially Effective | Tabletop exercise required |
Possible ratings:
- Effective
- Partially Effective
- Ineffective
- Not Tested
- Not Applicable
15. Threat Exposure Assessment
Consider the organization’s actual exposure.
| Factor | Assessment |
|---|---|
| Internet Exposure | Low / Medium / High |
| Asset Criticality | Low / Medium / High |
| Vulnerability Present | Yes / No / Unknown |
| Exploit Available | Yes / No / Unknown |
| Active Exploitation | Yes / No / Unknown |
| Threat Targeting Industry | Yes / No / Unknown |
| Existing Controls | Strong / Moderate / Weak |
| Third-Party Dependency | Yes / No |
| Overall Exposure | Low / Medium / High |
16. Threat Assessment Summary
| Factor | Result |
|---|---|
| Threat | [Threat] |
| Threat Actor | [Actor / Unknown] |
| Attack Vector | [Vector] |
| Affected Asset | [Asset] |
| Potential Impact | [Level] |
| Likelihood | [Level] |
| Exposure | [Level] |
| Existing Controls | [Summary] |
| Control Effectiveness | [Level] |
| Threat Severity | [Level] |
| Action Required | Yes / No |
17. Relationship to Security Risk
The threat assessment should be connected to the organization’s formal risk assessment.
Example:
Threat: Compromised privileged AWS credentials
↓
Threat Scenario: Attacker obtains administrator credentials through phishing.
↓
Vulnerability: Inadequate access restrictions / credential exposure.
↓
Risk Event: Unauthorized production access.
↓
Potential Impact: Customer data exposure and service disruption.
↓
Security Risk Assessment: Likelihood × Impact.
↓
Risk Treatment: MFA, least privilege, monitoring, access reviews, credential protection.
The Threat Assessment focuses primarily on the threat and attack scenario, while the Security Risk Assessment determines the broader organizational risk and treatment decision.
18. Required Actions
Where action is required, record it below.
| Action ID | Action | Type | Owner | Priority | Due Date | Status |
|---|---|---|---|---|---|---|
| TA-A01 | Enforce MFA for all privileged users | Preventive | IT | High | [Date] | Open |
| TA-A02 | Review privileged AWS roles | Preventive | Cloud Lead | High | [Date] | Open |
| TA-A03 | Add detection for suspicious login activity | Detective | Security | Medium | [Date] | Open |
Action types may include:
- Prevent
- Detect
- Respond
- Recover
- Transfer
- Monitor
- Accept
19. Threat Treatment Options
Depending on the assessment, the organization may:
Prevent
Implement controls to reduce the likelihood of the threat.
Detect
Improve monitoring and detection capabilities.
Respond
Improve incident response and containment.
Recover
Improve backup, recovery, and business continuity capabilities.
Transfer / Share
Use contractual arrangements, insurance, or third-party services where appropriate.
Monitor
Continue monitoring where the threat does not currently require additional treatment.
Accept
Accept the associated risk only where it falls within approved risk acceptance criteria.
20. AWS SaaS Example
Threat
Cloud account compromise.
Threat Actor
External cybercriminal.
Attack Vector
Phishing / credential theft.
Target
Privileged AWS account.
Attack Scenario
An attacker obtains the credentials of an employee with privileged cloud access and attempts to access production AWS resources.
Potential Impact
- Unauthorized production access
- Customer data exposure
- Unauthorized configuration changes
- Service disruption
- Security incident
- Regulatory or contractual consequences
Existing Controls
- MFA
- IAM roles
- Least privilege
- CloudTrail
- Security monitoring
- Quarterly access reviews
- Incident response procedure
Exposure
Medium to High, depending on the privileges and exposure of the compromised account.
Required Actions
- Verify MFA enforcement.
- Review privileged roles.
- Remove unnecessary permissions.
- Monitor suspicious authentication activity.
- Review access keys.
- Test incident response procedures.
Related Risk
R-001 – Unauthorized access to AWS production environment
The formal risk score and treatment should be determined through the organization’s approved Security Risk Assessment methodology.
21. Threat Assessment Decision
After completing the assessment, record the decision:
☐ No significant organizational exposure identified
☐ Continue monitoring
☐ Additional preventive controls required
☐ Additional detective controls required
☐ Vulnerability remediation required
☐ Risk assessment required / updated
☐ Incident investigation required
☐ Supplier assessment required
☐ Regulatory / privacy assessment required
☐ Management escalation required
☐ Other: __________________
22. Escalation Criteria
Immediate escalation should be considered where:
- Active exploitation is confirmed.
- Critical systems are targeted.
- Customer or personal data may be affected.
- Privileged credentials may be compromised.
- A critical vulnerability is exposed.
- There is evidence of unauthorized access.
- The threat could cause significant business disruption.
- Regulatory or contractual notification may be required.
Where an actual or suspected security incident exists, the Incident Management Procedure should be initiated.
23. Evidence
The following evidence may support the threat assessment:
- Threat intelligence report
- Security advisory
- Vulnerability report
- Security logs
- SIEM alerts
- EDR alerts
- Cloud logs
- VAPT report
- Penetration test results
- Security monitoring records
- Asset inventory
- Configuration evidence
- Access review
- Risk assessment
- Incident records
- Supplier communication
- Remediation records
24. Review and Reassessment
The assessment should be reviewed when:
- New intelligence becomes available.
- The threat becomes actively exploited.
- The affected technology changes.
- A vulnerability is discovered.
- New controls are implemented.
- An incident occurs.
- The organization’s exposure changes.
- Relevant regulatory or contractual requirements change.
The threat assessment should also be reviewed according to the organization’s defined security risk review cycle where applicable.
25. Final Threat Assessment Record
Threat
[Threat Name]
Threat Actor
[Actor / Unknown]
Attack Vector
[Vector]
Affected Assets
[Assets]
Threat Scenario
[Scenario]
Potential Impact
[Impact]
Likelihood
[Score / Reason]
Existing Controls
[Controls]
Control Effectiveness
[Assessment]
Threat Severity
[Critical / High / Medium / Low]
Organizational Exposure
[Low / Medium / High]
Required Treatment
[Actions]
Related Risk
[Risk ID]
Risk Owner
[Name / Role]
Assessment Decision
[Decision]
Assessor
[Name]
Approval
[Name / Role]
Date
[Date]
Next Review
[Date]
26. Quick Audit Checklist
| Check | Status |
|---|---|
| Threat clearly identified | ☐ |
| Threat source documented | ☐ |
| Threat intelligence source recorded | ☐ |
| Threat actor assessed where appropriate | ☐ |
| Attack vector identified | ☐ |
| Threat scenario documented | ☐ |
| Affected assets identified | ☐ |
| Affected information identified | ☐ |
| Potential impact assessed | ☐ |
| Likelihood assessed | ☐ |
| Organizational exposure assessed | ☐ |
| Existing controls identified | ☐ |
| Control effectiveness considered | ☐ |
| Threat severity determined | ☐ |
| Required actions identified | ☐ |
| Related risk identified | ☐ |
| Risk Register updated where necessary | ☐ |
| Incident escalation considered | ☐ |
| Evidence retained | ☐ |
| Review date established | ☐ |
Final Principle
A Threat Assessment should move from “What threat exists?” to “How could it affect us?”
Threat → Actor → Attack Vector → Scenario → Asset → Exposure → Impact → Existing Controls → Action → Risk
The goal is not simply to document threats. It is to determine which threats are relevant to the organization and what security action, if any, is required.