1. Purpose

The purpose of this procedure is to establish a structured process for collecting, assessing, analysing, communicating, and acting upon threat intelligence relevant to the organization.

Threat intelligence helps the organization understand:

• Who may target the organization
• What threats may affect the organization
• Which vulnerabilities or attack techniques are relevant
• How threats could affect information assets and services
• What preventive or detective measures may be required

The objective is to convert external and internal threat information into actionable security decisions.

---

2. Scope

This procedure applies to information security activities involving:

• Cybersecurity threats
• Threat actors
• Vulnerabilities
• Malware
• Phishing and social engineering
• Ransomware
• Credential attacks
• Cloud security threats
• Application security threats
• Supply-chain threats
• Data breaches
• Threat indicators
• Security incidents
• Industry-specific threats

It applies to relevant:

• Employees
• Security personnel
• IT and infrastructure teams
• Cloud teams
• Engineering teams
• Incident response teams
• Risk owners
• ISMS personnel
• Compliance and privacy personnel

---

3. What Is Threat Intelligence?

Threat intelligence is information about existing or emerging threats that has been collected, analysed, and interpreted to support security decisions.

There is an important difference between security information and threat intelligence.

Security Information

Raw information such as:

“A vulnerability has been reported in a software product.”

Threat Intelligence

Analysed information such as:

“The organization uses the affected software in an internet-facing production environment. The vulnerability is actively being exploited, creating a high-priority remediation requirement.”

Threat intelligence therefore moves from:

Information → Context → Analysis → Decision → Action

---

4. Threat Intelligence Sources

Threat intelligence may come from internal and external sources.

External Sources

Examples include:

• Government cybersecurity advisories
• CERT / CSIRT notifications
• Security vendors
• Cloud providers
• Software vendors
• Vulnerability databases
• Threat intelligence providers
• Industry security groups
• Security research organizations
• Professional security communities
• Customer security notifications
• Supplier security notifications
• Security conferences and publications

Internal Sources

Examples include:

• Security incidents
• Vulnerability assessments
• VAPT reports
• Penetration testing
• Security monitoring
• SIEM alerts
• EDR alerts
• Firewall events
• Cloud security monitoring
• Phishing reports
• Incident investigations
• Threat hunting
• Internal audit findings

---

5. Threat Intelligence Lifecycle

The organization’s threat intelligence process should follow a defined lifecycle:

Direction
↓
Collection
↓
Processing
↓
Analysis
↓
Dissemination
↓
Action
↓
Feedback & Improvement

---

6. Direction

The organization should first determine what threat intelligence it actually needs.

Threat intelligence requirements may be based on:

• Business risks
• Critical assets
• Customer requirements
• Technology environment
• Cloud platforms
• Industry
• Geographic exposure
• Regulatory requirements
• Previous incidents
• Known vulnerabilities

For example, an AWS SaaS company may prioritize intelligence relating to:

• AWS security threats
• Cloud account compromise
• IAM attacks
• API attacks
• Web application vulnerabilities
• Credential theft
• Ransomware
• Supply-chain attacks
• SaaS application vulnerabilities
• Customer data exposure

The organization should avoid collecting large amounts of intelligence that cannot be operationally used.

---

7. Threat Intelligence Requirements

The Security Lead should identify key intelligence requirements.

Example:

Intelligence Requirement	Why Required
Cloud account attacks	Protect AWS environment
Critical software vulnerabilities	Support vulnerability management
Credential theft	Protect user accounts
Phishing campaigns	Protect employees
Web application attacks	Protect SaaS platform
Ransomware	Protect business operations
Supply-chain attacks	Manage supplier risks
Data breach trends	Protect customer information
Industry-specific threats	Understand sector risks

---

8. Collection

Relevant information should be collected from approved and reliable sources.

Collection methods may include:

• Security alert subscriptions
• Threat intelligence feeds
• Vendor advisories
• Cloud provider notifications
• Security monitoring platforms
• Vulnerability databases
• Security research
• Industry communities
• Government advisories
• Incident reports
• Internal security monitoring

Sources should be reviewed periodically to ensure they remain reliable and relevant.

---

9. Threat Intelligence Classification

Threat intelligence can be classified into different levels.

Strategic Intelligence

Provides information for management and long-term risk decisions.

Examples:

• Emerging cybersecurity trends
• Changes in threat landscape
• Industry attack trends
• Major changes in threat actors

Tactical Intelligence

Describes attacker methods and techniques.

Examples:

• Phishing techniques
• Credential attacks
• MITRE ATT&CK techniques
• Cloud attack methods
• Application attack patterns

Operational Intelligence

Provides information about ongoing or likely attacks.

Examples:

• Active campaigns
• Current attack activity
• Targeted sectors
• Emerging attack techniques

Technical Intelligence

Provides technical indicators and information.

Examples:

• IP addresses
• Domains
• URLs
• Hashes
• Malware indicators
• Vulnerability identifiers
• Detection signatures

The organization should use the level of intelligence appropriate to its size, risk, and security capability.

---

10. Threat Intelligence Analysis

Collected information should be analysed before significant action is taken.

The analysis should consider:

• Source reliability
• Information accuracy
• Date and freshness
• Relevance to the organization
• Affected technologies
• Affected assets
• Threat actor
• Attack technique
• Exploitability
• Potential impact
• Existing controls
• Required action

A simple assessment can use:

Reliable Source + Relevant Threat + Organizational Exposure + Potential Impact = Actionable Intelligence

---

11. Threat Relevance Assessment

For each significant threat, determine:

1. Is the threat real?

Check the reliability of the source and supporting evidence.

2. Does it affect us?

Determine whether the organization uses the affected technology, service, supplier, or process.

3. How exposed are we?

Consider:

• Internet exposure
• Configuration
• Vulnerability status
• Authentication controls
• Network controls
• Existing security measures

4. What could happen?

Consider:

• Data exposure
• Unauthorized access
• Service disruption
• Financial impact
• Customer impact
• Privacy impact
• Regulatory impact

5. What should we do?

Determine whether monitoring, remediation, risk treatment, or incident response is required.

---

12. Threat Severity

A practical classification may be used:

Severity	Description	Typical Action
Critical	Immediate or significant threat to critical systems/data	Immediate escalation and action
High	Significant threat with credible organizational exposure	Prompt remediation
Medium	Relevant threat requiring monitoring or planned action	Track and address
Low	Limited relevance or impact	Monitor

These categories should be aligned with the organization’s existing risk and incident management methodology.

---

13. Threat Intelligence and Risk Management

Threat intelligence should feed the organization’s risk management process.

Example:

Threat Intelligence
↓
New cloud account attack identified
↓
Organization checks AWS environment
↓
Exposure identified
↓
Risk Register reviewed
↓
Likelihood / impact reassessed
↓
Risk treatment updated
↓
Additional controls implemented
↓
Residual risk assessed

Threat intelligence does not automatically mean that a new risk must be created. The organization should determine whether it changes an existing risk or introduces a new one.

---

14. Threat Intelligence and Vulnerability Management

Threat intelligence should support vulnerability prioritization.

For example:

A vulnerability may initially be classified as technically significant.

If threat intelligence confirms that:

• The vulnerability is actively exploited,
• The organization’s affected system is internet-facing, and
• The affected system processes sensitive information,

the organization may prioritize remediation based on the actual threat and exposure.

This provides a more risk-based approach than relying solely on a vulnerability score.

---

15. Threat Intelligence and Incident Management

Threat intelligence may indicate that an attack is occurring or may have occurred.

Examples:

• An IP address associated with an active attack is detected in firewall logs.
• A known malicious domain is contacted by an employee device.
• Credentials associated with the organization appear in a threat report.
• A threat actor is targeting the organization’s industry.

The information should be escalated to the Incident Management Procedure when there is evidence of an actual or suspected security incident.

---

16. Technical Indicators

Where appropriate, technical indicators may be collected and analysed.

Examples include:

• IP addresses
• Domains
• URLs
• File hashes
• Malware signatures
• Email addresses
• Vulnerability identifiers
• Attack patterns
• User-agent patterns
• Cloud activity indicators

Technical indicators should be handled carefully because indicators can become outdated or may generate false positives.

---

17. Threat Intelligence Processing

Raw intelligence should be processed before being distributed.

Processing may include:

• Removing duplicates
• Validating information
• Normalizing technical indicators
• Removing obsolete information
• Categorizing threats
• Identifying affected assets
• Linking vulnerabilities to systems
• Determining confidence
• Adding organizational context

The objective is to provide useful information rather than forwarding large volumes of raw alerts.

---

18. Threat Intelligence Dissemination

Relevant intelligence should be communicated to the appropriate stakeholders.

Intelligence	Recipient
Critical vulnerability	Security / IT / Engineering
Cloud threat	Cloud / Infrastructure
Application attack	Engineering / Security
Phishing campaign	IT / HR / Employees
Regulatory security development	Compliance / Legal
Industry threat trend	Management / Security
Active attack indicators	SOC / Incident Response
Supplier threat	Procurement / Security

Critical intelligence should be communicated immediately rather than waiting for scheduled meetings.

---

19. Threat Intelligence Action Tracking

Where action is required, record:

Field	Description
Intelligence ID	Unique reference
Date Identified	Date received
Source	Intelligence source
Threat	Threat description
Threat Actor	If known
Technique	Attack technique
Affected Asset	Relevant asset
Vulnerability	If applicable
Relevance	Organizational relevance
Severity	Critical / High / Medium / Low
Confidence	Confidence in intelligence
Action	Required response
Owner	Responsible person
Due Date	Target date
Status	Open / In Progress / Closed
Evidence	Supporting evidence
Closure Date	Completion date

---

20. Example – AWS SaaS Company

An AWS-based SaaS company receives threat intelligence reporting an active campaign targeting cloud accounts through stolen credentials.

Step 1 – Intelligence Received

Security receives the threat information.

Step 2 – Validation

The source and supporting information are reviewed.

Step 3 – Organizational Assessment

The company confirms that AWS is its production platform.

Step 4 – Exposure Assessment

The Security and Cloud teams review:

• IAM users
• Privileged roles
• MFA
• Authentication logs
• Recent suspicious activity
• Access keys
• CloudTrail activity

Step 5 – Action

The company:

• Reviews privileged accounts.
• Rotates potentially exposed credentials.
• Confirms MFA enforcement.
• Reviews suspicious authentication activity.
• Strengthens monitoring where necessary.

Step 6 – Risk Review

The related cloud-account compromise risk is reassessed.

Step 7 – Evidence

Evidence may include:

• Threat intelligence report
• Applicability assessment
• IAM review
• CloudTrail logs
• Credential rotation records
• Change records
• Risk assessment
• Management communication

This demonstrates that threat intelligence is being converted into operational security action.

---

21. Threat Intelligence Register

A simple register can be maintained.

ID	Date	Source	Threat	Affected Asset	Severity	Action Required	Owner	Status
TI-001	[Date]	Security Advisory	Cloud credential attack	AWS	High	Review IAM/MFA	Cloud Lead	Closed
TI-002	[Date]	Vendor Advisory	Critical vulnerability	SaaS Application	Critical	Patch component	Engineering	In Progress
TI-003	[Date]	Industry Source	Phishing campaign	Employees	Medium	Awareness communication	IT/HR	Closed

---

22. Threat Intelligence Sources Register

The organization may maintain a separate register containing:

Source	Type	Area	Owner	Frequency	Reliability	Status
[Source]	Security Advisory	Vulnerabilities	Security Lead	Daily	High	Active
[Source]	Cloud Provider	Cloud Security	Cloud Lead	As Received	High	Active
[Source]	Industry Group	Sector Threats	ISMS Manager	Monthly	Medium	Active

The Special Interest Group Register may be used where appropriate instead of maintaining duplicate records.

---

23. Roles and Responsibilities

Top Management

• Support threat intelligence activities.
• Review significant threats affecting business objectives.
• Provide resources for appropriate treatment.

ISMS / Security Manager

• Define threat intelligence requirements.
• Maintain relevant sources.
• Coordinate collection and analysis.
• Assess organizational relevance.
• Coordinate actions and risk updates.
• Maintain records.

IT / Cloud / Engineering

• Assess technical threats.
• Validate exposure.
• Implement technical controls and remediation.
• Provide evidence of actions.

Incident Response Team

• Investigate intelligence indicating an actual or suspected incident.
• Coordinate containment and response.
• Preserve evidence.

Risk Owners

• Assess changes to assigned risks.
• Approve or implement appropriate risk treatment.

Compliance / Privacy / Legal

• Assess threats with regulatory, contractual, or privacy implications.

---

24. Threat Intelligence Retention

Threat intelligence records should be retained according to the organization’s documented information retention requirements.

Records may include:

• Intelligence reports
• Security advisories
• Analysis records
• Threat registers
• Technical indicators
• Risk assessments
• Remediation records
• Incident records
• Communication records
• Management review records

Where technical indicators are retained, obsolete indicators should be periodically reviewed and removed or archived as appropriate.

---

25. Metrics

The organization may monitor metrics such as:

• Number of relevant intelligence items received
• Number of threats assessed
• Number of actionable threats
• Number of critical/high threats
• Average time to assess critical intelligence
• Number of vulnerabilities prioritized using threat intelligence
• Number of risks updated due to threat intelligence
• Number of incidents identified through threat intelligence
• Percentage of critical actions completed within target timeframe

Metrics should be selected based on organizational size and security maturity.

---

26. Review and Improvement

The threat intelligence process should be periodically reviewed to determine:

• Whether current sources remain relevant
• Whether intelligence is actionable
• Whether important threats are being missed
• Whether alerts are creating excessive noise
• Whether response times are appropriate
• Whether intelligence is reaching the correct teams
• Whether risk assessments are being updated appropriately
• Whether additional sources are required

Lessons learned from incidents should be used to improve future intelligence requirements.

---

27. Relationship With Other ISMS Documents

The Threat Intelligence Procedure should connect with:

Special Interest Group Register
→ Identifies relevant external communities and information sources.

External Security Information Monitoring Procedure
→ Defines the broader process for monitoring external information.

Risk Assessment / Risk Register
→ Assesses risks identified or changed through threat intelligence.

Vulnerability Management Procedure
→ Prioritizes and remediates relevant vulnerabilities.

Incident Management Procedure
→ Responds when intelligence indicates an actual or suspected incident.

Security Incident Register
→ Records confirmed or suspected incidents.

Security Awareness Procedure
→ Uses relevant threat information to improve employee awareness.

Supplier Security Management
→ Assesses threats affecting critical suppliers.

Management Review
→ Provides management visibility of significant threat developments.

---

28. Quick Implementation for Startups

A startup does not necessarily need a dedicated threat intelligence platform.

A practical approach can be:

Identify Critical Assets
↓
Identify Threat Intelligence Requirements
↓
Select Reliable Sources
↓
Monitor Relevant Intelligence
↓
Validate Important Information
↓
Assess Organizational Exposure
↓
Update Risk / Vulnerability / Incident Records
↓
Take Action
↓
Verify and Record Evidence
↓
Review and Improve

For a small AWS SaaS company, existing sources such as cloud-provider advisories, software-vendor advisories, vulnerability information, security monitoring, incident records, and relevant industry sources may provide a useful starting point.

A dedicated commercial threat intelligence platform should be considered when the organization’s volume, threat exposure, monitoring requirements, or security operations justify it.

---

29. Audit Checklist

Audit Question	Evidence
Has the organization defined its threat intelligence requirements?	Intelligence requirements
Are relevant sources identified?	Source Register
Are sources monitored?	Alerts / subscriptions
Is intelligence validated where appropriate?	Analysis records
Is relevance to the organization assessed?	Applicability assessment
Are significant threats analysed?	Threat analysis
Are risks updated where necessary?	Risk Register
Are vulnerabilities prioritized using relevant intelligence?	Vulnerability records
Are actionable threats communicated?	Communication records
Are required actions tracked?	Action register / tickets
Are actual incidents escalated?	Incident records
Is evidence retained?	ISMS records
Are intelligence sources periodically reviewed?	Review records
Is the process continually improved?	Improvement actions

---

30. Final Principle

Effective threat intelligence is not about collecting the largest amount of security information.

It is about turning relevant information into useful decisions:

Collect → Validate → Analyse → Contextualize → Prioritize → Act → Verify → Learn → Improve