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:

1. Maintain visibility of relevant threats.
2. Determine whether external threats affect the organization.
3. Track analysis and decisions.
4. Link intelligence to vulnerabilities and risks.
5. Support incident detection and response.
6. Track security actions resulting from intelligence.
7. Provide evidence for internal and external audits.
8. 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