1. Purpose
The Threat Intelligence Register is used to record, track, assess, and monitor relevant threat intelligence received by the organization.
It provides a central record of:
- Threat intelligence sources
- Identified threats
- Affected technologies or assets
- Threat actors and attack techniques, where known
- Organizational relevance
- Exposure and potential impact
- Required actions
- Related risks and vulnerabilities
- Owners and status
- Evidence and follow-up actions
The register should focus on relevant and actionable intelligence, rather than recording every security alert or advisory received.
2. Objectives
The Threat Intelligence Register helps the organization:
- Maintain visibility of relevant threats.
- Determine whether external threats affect the organization.
- Track analysis and decisions.
- Link intelligence to vulnerabilities and risks.
- Support incident detection and response.
- Track security actions resulting from intelligence.
- Provide evidence for internal and external audits.
- Support management reporting and continual improvement.
3. When to Create a Register Entry
An entry should normally be created when threat intelligence:
- Affects technology used by the organization.
- Relates to an important organizational asset.
- Indicates active exploitation.
- Identifies a significant vulnerability.
- Relates to the organization’s industry.
- Indicates a threat targeting customers or suppliers.
- May affect customer or sensitive information.
- Could change an existing security risk.
- Requires investigation or action.
- May indicate a potential security incident.
Routine or clearly irrelevant information does not need to be recorded.
4. Threat Intelligence Register Template
| Field | Description |
|---|---|
| Intelligence ID | Unique identifier, e.g., TI-2026-001 |
| Date Identified | Date intelligence was received/identified |
| Source | Vendor, CERT, government, researcher, etc. |
| Source Reference | URL, advisory ID, report number, etc. |
| Published Date | Date source published the information |
| Threat Category | Phishing, ransomware, cloud, vulnerability, etc. |
| Threat Description | Short description of the threat |
| Threat Actor | Actor name, if reliably known |
| Attack Technique | Technique or attack method |
| Affected Technology | Application, OS, cloud service, library, etc. |
| Affected Asset | Organizational asset/system |
| Vulnerability / CVE | Relevant vulnerability identifier |
| Source Reliability | High / Medium / Low |
| Intelligence Confidence | High / Medium / Low |
| Organizational Relevance | Not Applicable / Monitor / Action Required / Critical |
| Exposure | Low / Medium / High / Critical |
| Potential Impact | Low / Medium / High / Critical |
| Threat Severity | Low / Medium / High / Critical |
| Existing Controls | Controls currently addressing the threat |
| Related Risk ID | Link to Risk Register |
| Related Vulnerability ID | Link to Vulnerability Register |
| Related Incident ID | Link to Incident Register, if applicable |
| Required Action | Action required |
| Action Owner | Responsible person/team |
| Priority | Critical / High / Medium / Low |
| Target Date | Expected completion date |
| Status | Open / In Progress / Monitoring / Closed |
| Evidence | Supporting evidence |
| Closure Date | Date action was completed |
| Reviewer | Person who reviewed the intelligence |
| Review Date | Date of review |
| Comments | Additional information |
5. Example Threat Intelligence Register
| ID | Threat | Source | Affected Asset | Relevance | Severity | Action | Owner | Status |
|---|---|---|---|---|---|---|---|---|
| TI-001 | Active exploitation of cloud authentication vulnerability | Cloud Vendor | AWS Production | Action Required | Critical | Validate exposure and patch | Cloud Lead | In Progress |
| TI-002 | Credential phishing campaign targeting SaaS employees | Security Vendor | Corporate Users | Action Required | High | Awareness communication and monitoring | IT / HR | Open |
| TI-003 | Vulnerability in third-party library | Software Vendor | SaaS Application | Action Required | High | Upgrade dependency and rescan | Engineering | Closed |
| TI-004 | Ransomware campaign targeting healthcare organizations | CERT Advisory | Corporate IT | Monitor | Medium | Monitor for relevance | Security Lead | Monitoring |
| TI-005 | Malicious domain campaign | Threat Intelligence Provider | Internet-facing systems | Action Required | High | Add indicators to monitoring/blocking | SOC | Closed |
6. Detailed Threat Intelligence Record
For significant threats, the organization may maintain a more detailed analysis record.
Intelligence ID
TI-2026-001
Threat
Active exploitation of a vulnerability affecting a software component used by the organization.
Source
Official software vendor security advisory.
Source Reliability
High
Confidence
High
Affected Technology
Application dependency used by the production SaaS platform.
Affected Asset
AWS production application.
Organizational Exposure
High
The component is deployed in an internet-facing production environment.
Potential Impact
Potential unauthorized access or compromise of customer-facing systems.
Existing Controls
- Vulnerability scanning
- Secure development practices
- CI/CD security checks
- Web application protection
- Logging and monitoring
- Access controls
Required Action
Upgrade the affected dependency, perform security testing, and validate remediation through vulnerability scanning.
Related Records
- Vulnerability: VUL-2026-014
- Risk: R-2026-007
Owner
Engineering Lead
Status
In Progress
7. Threat Intelligence Source Register
The organization may maintain a separate source register.
| ID | Source | Type | Area | Reliability | Monitoring Method | Owner | Frequency |
|---|---|---|---|---|---|---|---|
| SRC-001 | Cloud Provider Security Advisories | Vendor | Cloud | High | Email / Portal | Cloud Lead | As received |
| SRC-002 | Government Cyber Advisories | Government | Cybersecurity | High | Subscription | Security Lead | As received |
| SRC-003 | Software Vendor Advisories | Vendor | Applications | High | Email / Portal | Engineering | As received |
| SRC-004 | Security Research Sources | Research | Threats | Medium | Newsletter | Security Lead | Weekly |
| SRC-005 | Industry Security Group | Industry | Sector threats | Medium | Membership | Compliance | Monthly |
The source register and threat intelligence register serve different purposes.
Source Register: Where do we obtain intelligence?
Threat Intelligence Register: What relevant intelligence did we receive and what did we do about it?
8. Organizational Relevance
Each significant intelligence item should be assessed against the organization’s environment.
Questions
- Do we use the affected technology?
- Is the technology within the ISMS scope?
- Is the affected asset internet-facing?
- Is the vulnerability present?
- Is exploitation active?
- Are critical assets affected?
- Could customer information be affected?
- Could contractual requirements be affected?
- Could regulatory requirements be affected?
- Are existing controls sufficient?
- Is immediate action required?
Possible outcomes:
| Result | Meaning |
|---|---|
| Not Applicable | Organization is not affected |
| Monitor | Potential relevance but no immediate action |
| Action Required | Specific security action is required |
| Critical | Immediate investigation/action is required |
9. Threat Intelligence Severity
Severity should be based on the organization’s circumstances rather than simply copying the severity assigned by an external source.
Critical
Examples:
- Active exploitation affecting a critical system
- Evidence of compromise
- Customer data potentially exposed
- Privileged credential compromise
High
Examples:
- High-risk vulnerability affecting an important system
- Significant threat targeting the organization’s industry
- Credible threat against an internet-facing asset
Medium
Examples:
- Relevant emerging threat with limited exposure
- Threat requiring additional monitoring
Low
Examples:
- Low-impact threat
- Limited organizational relevance
10. Linking Threat Intelligence to Risk
Threat intelligence should be connected to the Risk Register where appropriate.
Example:
Threat Intelligence
Active exploitation of compromised cloud credentials.
↓
Exposure Assessment
Privileged AWS accounts identified as potentially exposed.
↓
Risk Register
Unauthorized access to AWS production environment.
↓
Risk Treatment
- MFA
- Least privilege
- Privileged access management
- Access reviews
- Logging
- Monitoring
↓
Verification
Access review and security monitoring evidence.
Not every threat intelligence record creates a new risk. Existing risks should be updated where the intelligence changes the organization’s risk assessment.
11. Linking Threat Intelligence to Vulnerability Management
Where intelligence relates to a vulnerability:
Threat Intelligence
→ Vulnerability identified
→ Confirm affected asset
→ Determine exposure
→ Assess exploitability
→ Prioritize remediation
→ Remediate
→ Verify
→ Close
The Threat Intelligence Register should reference the corresponding Vulnerability Register entry.
12. Linking Threat Intelligence to Incident Management
Threat intelligence may provide an early indication of an incident.
Examples:
- Stolen organizational credentials appear in a breach dataset.
- Malicious traffic is detected from an identified threat campaign.
- A known attacker is targeting the organization’s infrastructure.
- A vulnerable system shows signs of exploitation.
In such cases, the incident response process should be initiated as appropriate.
The Threat Intelligence Register should reference the related Incident ID.
13. Threat Intelligence Action Tracking
Actions resulting from intelligence should be tracked.
| Action ID | Intelligence ID | Action | Owner | Priority | Due Date | Status | Evidence |
|---|---|---|---|---|---|---|---|
| ACT-001 | TI-001 | Patch affected component | Engineering | Critical | 02-Oct | In Progress | Deployment record |
| ACT-002 | TI-002 | Conduct phishing awareness campaign | HR / IT | High | 03-Oct | Open | Training record |
| ACT-003 | TI-003 | Update vulnerable library | Engineering | High | 01-Oct | Closed | Scan report |
14. Status Values
Recommended status values include:
- New – Intelligence has been received but not assessed.
- Under Assessment – Relevance is being determined.
- Action Required – Action has been identified.
- In Progress – Action is being implemented.
- Monitoring – No immediate action, but continued monitoring is required.
- Closed – Required action has been completed and verified.
- Not Applicable – The threat does not affect the organization.
15. Evidence
Possible audit evidence includes:
- Original security advisory
- Threat intelligence report
- Email notification
- Threat intelligence feed
- Source reference
- Applicability assessment
- Analyst review
- Vulnerability scan
- Penetration test
- Risk assessment
- Risk Register update
- Remediation ticket
- Change record
- Incident record
- Security monitoring evidence
- Management communication
- Closure verification
The evidence should demonstrate:
Threat Identified → Assessed → Decision Made → Action Taken → Verified
16. Review Frequency
The register should be reviewed according to the organization’s threat environment.
Examples:
- Critical intelligence: immediately/as received
- High-risk intelligence: daily or as required
- Active campaigns: ongoing monitoring
- General intelligence: weekly/monthly review
- Source effectiveness: periodic review
These are example frequencies and should be adjusted based on organizational risk.
17. Metrics
The organization may monitor:
| Metric | Example |
|---|---|
| Intelligence items received | 50/month |
| Items assessed | 35/month |
| Relevant intelligence | 15/month |
| Actionable intelligence | 8/month |
| Critical intelligence | 2/month |
| Average assessment time | 4 hours |
| Open actions | 5 |
| Overdue actions | 1 |
| Intelligence-related vulnerabilities | 6 |
| Intelligence-related incidents | 1 |
Metrics should be used to improve the process rather than simply increase the volume of recorded intelligence.
18. Roles
Security / ISMS Manager
- Maintains the register.
- Reviews intelligence.
- Coordinates assessment.
- Assigns actions.
- Tracks closure.
IT / Cloud / Engineering
- Assess technical exposure.
- Validate vulnerabilities.
- Implement remediation.
- Provide evidence.
Risk Owner
- Assess changes to the relevant risk.
- Approve risk treatment where applicable.
Incident Response Team
- Investigate potential compromise.
- Escalate confirmed or suspected incidents.
Compliance / Legal / Privacy
- Assess regulatory, contractual, or privacy implications where applicable.
19. Review and Closure
An intelligence record should not be closed simply because an action was assigned.
Before closure, the responsible reviewer should confirm:
- The threat was assessed.
- Organizational exposure was determined.
- Required action was completed.
- Remediation was verified where applicable.
- Related risk was reviewed.
- Related vulnerability was closed or updated.
- Related incident was addressed where applicable.
- Evidence was retained.
Closure Principle
Identify → Assess → Act → Verify → Record → Close
20. Startup-Friendly Approach
For a small or growing SaaS organization, the Threat Intelligence Register can initially be maintained in:
- Excel
- Google Sheets
- GRC platform
- Security management platform
- Ticketing system
A dedicated threat intelligence platform is not automatically necessary.
A simple setup can use:
Cloud Provider Alerts
+
Software Vendor Advisories
+
Government/CERT Advisories
+
Vulnerability Information
+
Security Monitoring
↓
Threat Intelligence Register
↓
Risk / Vulnerability / Incident Process
As the organization grows, the process can be integrated with SIEM, vulnerability management, ticketing, or GRC tools.
21. Recommended Register Structure
For practical ISO 27001 implementation, maintain at least these four related records:
1. Threat Intelligence Source Register
Where do we get intelligence?
2. Threat Intelligence Register
What relevant threats did we identify?
3. Threat Intelligence Action Register
What did we do about them?
4. Threat Assessment
How does a significant threat affect our organization?
This creates a clear audit trail:
Source → Intelligence → Assessment → Risk/Vulnerability/Incident → Action → Evidence → Closure
22. Audit Checklist
| Question | Evidence |
|---|---|
| Are relevant intelligence sources identified? | Source Register |
| Is threat intelligence recorded? | Threat Intelligence Register |
| Is source reliability considered? | Source assessment |
| Is organizational relevance assessed? | Analysis record |
| Are significant threats assessed? | Threat Assessment |
| Are vulnerabilities linked? | Vulnerability Register |
| Are risks updated where necessary? | Risk Register |
| Are actions assigned to owners? | Action Register |
| Are critical threats escalated? | Escalation records |
| Are actions verified? | Verification evidence |
| Are incidents linked where applicable? | Incident Register |
| Are records retained? | ISMS records |
| Is the process periodically reviewed? | Review records |
| Are lessons learned incorporated? | Improvement records |
23. Final Principle
The Threat Intelligence Register should answer five simple questions:
What threat did we identify?
Why does it matter to us?
What did we decide?
What action did we take?
Can we prove that we addressed it?
The complete workflow is:
Source → Intelligence → Validate → Assess → Link → Act → Verify → Evidence → Close → Improve