1. Purpose
The purpose of this procedure is to establish a structured process for collecting, validating, analysing, communicating, and acting upon information about information security threats that may affect the organization.
The procedure ensures that relevant threat intelligence is converted into actionable information that supports:
- Information security risk assessment
- Vulnerability management
- Security monitoring
- Incident detection and response
- Security control improvement
- Business continuity
- Security awareness
- Management decision-making
The objective is not to collect the maximum amount of threat information, but to identify relevant and actionable intelligence for the organization’s environment.
2. Scope
This procedure applies to threat intelligence relating to:
- Cybersecurity threats
- Threat actors
- Attack techniques
- Malware
- Ransomware
- Phishing
- Credential compromise
- Cloud attacks
- Application attacks
- API attacks
- Supply-chain attacks
- Vulnerability exploitation
- Data theft
- Denial-of-service attacks
- Insider threats
- Industry-specific threats
It applies to relevant:
- Security personnel
- ISMS personnel
- IT and infrastructure teams
- Cloud teams
- Engineering teams
- DevOps teams
- Incident response personnel
- Risk owners
- Compliance and privacy personnel
3. What Is Threat Intelligence?
Threat intelligence is information about threats that has been collected, processed, analysed, and given context so that the organization can make informed security decisions.
There is a difference between raw security information and threat intelligence.
Raw Security Information
“A critical vulnerability has been identified in a software component.”
Threat Intelligence
“The organization uses the affected component in an internet-facing production application, and credible sources report active exploitation. The vulnerability therefore requires immediate assessment and potential remediation.”
The process is:
Information → Validation → Context → Analysis → Decision → Action
4. Objectives
The threat intelligence process should help the organization:
- Identify emerging threats.
- Understand relevant threat actors and attack techniques.
- Identify vulnerabilities that may be actively exploited.
- Determine whether the organization is exposed.
- Improve security monitoring.
- Prioritize vulnerability remediation.
- Update risk assessments.
- Improve incident detection and response.
- Support security awareness.
- Improve security controls.
5. Threat Intelligence Requirements
The organization should first determine what intelligence it actually needs.
Threat intelligence requirements should be based on:
- Business objectives
- ISMS scope
- Critical assets
- Information security risks
- Technology environment
- Cloud platforms
- Applications
- Industry
- Customer requirements
- Regulatory requirements
- Previous incidents
- Known vulnerabilities
Example – AWS SaaS Startup
A SaaS organization using AWS may require intelligence concerning:
- AWS account compromise
- IAM attacks
- Cloud misconfiguration exploitation
- Web application attacks
- API attacks
- Credential theft
- Ransomware
- Supply-chain attacks
- SaaS vulnerabilities
- Customer data exposure
6. Threat Intelligence Sources
Threat intelligence may be obtained 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 associations
- Security communities
- Security researchers
- Professional forums
- Customer security notifications
- Supplier security notifications
Internal Sources
Examples include:
- Security incidents
- Security monitoring
- SIEM alerts
- EDR alerts
- Firewall logs
- Cloud security monitoring
- Vulnerability assessments
- VAPT
- Penetration testing
- Phishing reports
- Threat hunting
- Incident investigations
- Internal audit findings
7. Threat Intelligence Lifecycle
The organization should follow a defined lifecycle:
Direction
↓
Collection
↓
Processing
↓
Analysis
↓
Dissemination
↓
Action
↓
Feedback & Improvement
Each stage should have an identified owner where appropriate.
8. Direction
The Security / ISMS function should define intelligence requirements based on organizational risks.
Questions should include:
- What assets are most important?
- What threats could affect those assets?
- Which technologies are critical?
- Which threats are relevant to our industry?
- Which threats are currently active?
- What information would change a security decision?
- Which teams need the intelligence?
The organization should avoid collecting large amounts of intelligence that cannot be analysed or acted upon.
9. Collection
Relevant information should be collected from approved sources.
Collection methods may include:
- Security advisory subscriptions
- Threat intelligence feeds
- Vendor alerts
- Cloud provider notifications
- Security monitoring tools
- Vulnerability databases
- Security research
- Industry communities
- Government alerts
- Customer notifications
- Supplier notifications
- Internal security events
Sources should be reviewed periodically to determine whether they remain relevant and reliable.
10. Source Reliability
The organization should consider the reliability of each intelligence source.
Example:
| Reliability | Description |
|---|---|
| High | Official government, vendor, or trusted security source |
| Medium | Established industry or security research source |
| Low | Unverified or limited-source information |
Source reliability should be considered together with the confidence of the specific information.
An otherwise reliable source does not mean that every individual report is automatically applicable to the organization.
11. Processing
Raw information should be processed before significant decisions are made.
Processing may include:
- Removing duplicate information
- Validating information
- Checking publication dates
- Removing obsolete information
- Categorizing threats
- Identifying affected technologies
- Identifying relevant assets
- Normalizing technical indicators
- Assigning confidence
- Linking information to existing risks
The objective is to turn raw information into useful security intelligence.
12. Threat Intelligence Categories
The organization may classify intelligence into the following categories.
Strategic Intelligence
Supports management and long-term security decisions.
Examples:
- Major changes in the threat landscape
- Industry attack trends
- Emerging cybersecurity risks
- Significant threat actor activity
Tactical Intelligence
Describes how attackers operate.
Examples:
- Attack techniques
- Phishing methods
- Credential attacks
- Cloud attack techniques
- Application attack patterns
Operational Intelligence
Provides information about current or developing attacks.
Examples:
- Active campaigns
- Targeted industries
- Current attack activity
- Emerging attack methods
Technical Intelligence
Provides technical indicators.
Examples:
- IP addresses
- Domains
- URLs
- File hashes
- Malware indicators
- CVEs
- Detection signatures
The organization should use only the categories appropriate to its security requirements.
13. Intelligence Analysis
Threat intelligence should be analysed to determine its relevance.
The analysis should consider:
- Source reliability
- Information confidence
- Information freshness
- Threat actor
- Attack technique
- Attack vector
- Affected technology
- Organizational exposure
- Asset criticality
- Vulnerability status
- Existing controls
- Potential impact
- Required action
The analyst should answer:
Does this threat actually matter to our organization?
14. Organizational Relevance Assessment
Each significant intelligence item should be assessed.
Questions
- Do we use the affected technology?
- Is the affected system within our ISMS scope?
- Is the affected asset internet-facing?
- Do we have the affected vulnerability?
- Is exploitation currently occurring?
- Do existing controls reduce the exposure?
- Could customers or personal data be affected?
- Could contractual or regulatory obligations be affected?
- Does the information change an existing risk?
- Is immediate action required?
Possible results:
- Not Applicable
- Applicable – Monitor
- Applicable – Action Required
- Critical – Immediate Action
15. Threat Intelligence Confidence
Where appropriate, assign a confidence level.
| Confidence | Meaning |
|---|---|
| High | Information is supported by reliable and/or multiple sources |
| Medium | Information appears credible but requires additional validation |
| Low | Limited or unverified information |
Confidence should be considered before taking significant action.
16. Threat Intelligence and Vulnerability Management
Threat intelligence should support vulnerability prioritization.
For example:
A vulnerability may have a high technical severity.
However, if threat intelligence shows that the vulnerability is:
- Actively exploited,
- Present in the organization’s environment,
- Internet-facing, and
- Affecting a critical system,
the organization may prioritize remediation accordingly.
The relationship is:
Vulnerability → Threat Intelligence → Exposure → Risk → Remediation Priority
17. Threat Intelligence and Risk Management
Threat intelligence may identify a new threat or change an existing risk.
Example:
Threat intelligence identifies new cloud credential attacks
↓
Organization reviews AWS environment
↓
Exposure identified
↓
Existing risk reassessed
↓
Risk treatment reviewed
↓
Additional controls implemented
↓
Residual risk reassessed
Threat intelligence should therefore feed into the organization’s Risk Assessment and Risk Register where relevant.
Not every intelligence item requires a new risk entry.
18. Threat Intelligence and Incident Management
Threat intelligence should be escalated when it indicates an actual or suspected security incident.
Examples:
- Organization credentials appear in a breach dataset.
- Known malicious traffic is detected against production.
- An employee device communicates with a known malicious domain.
- A threat actor is actively targeting the organization’s infrastructure.
- Evidence indicates exploitation of a known vulnerability.
The Incident Management Procedure should be initiated where appropriate.
19. Technical Indicators
Where appropriate, threat intelligence may include:
- IP addresses
- Domains
- URLs
- File hashes
- Malware signatures
- Email addresses
- CVE identifiers
- User-agent patterns
- Attack patterns
- Cloud activity indicators
Technical indicators should be validated before being used for automated blocking or detection.
Indicators should also be periodically reviewed because they may become obsolete.
20. Threat Intelligence Analysis Record
For significant intelligence, the following information may be recorded:
| Field | Details |
|---|---|
| Intelligence ID | TI-XXX |
| Date Identified | [Date] |
| Source | [Source] |
| Threat | [Threat] |
| Threat Actor | [If known] |
| Attack Technique | [Technique] |
| Affected Technology | [Technology] |
| Affected Asset | [Asset] |
| Vulnerability | [CVE / Identifier] |
| Source Reliability | High / Medium / Low |
| Confidence | High / Medium / Low |
| Organizational Exposure | Low / Medium / High |
| Potential Impact | Low / Medium / High / Critical |
| Severity | [Level] |
| Action Required | Yes / No |
| Owner | [Person / Role] |
| Related Risk | [Risk ID] |
| Related Vulnerability | [VUL ID] |
| Status | Open / Closed |
21. Dissemination
Relevant intelligence should be communicated to the appropriate stakeholders.
| Intelligence | Recipient |
|---|---|
| Critical vulnerability | Security / IT / Engineering |
| Cloud threat | Cloud / Infrastructure |
| Application threat | Engineering / Security |
| Phishing campaign | IT / HR / Employees |
| Supplier threat | Procurement / Security |
| Privacy-related threat | Privacy / Legal |
| Regulatory development | Compliance / Legal |
| Major threat trend | Management |
Critical intelligence should be communicated immediately.
22. Threat Intelligence Action
Where action is required, the responsible owner should determine the appropriate response.
Possible actions include:
- Patch vulnerability
- Change configuration
- Restrict access
- Block malicious indicators
- Increase monitoring
- Review privileged accounts
- Rotate credentials
- Conduct threat hunting
- Perform security testing
- Update security controls
- Update risk assessment
- Update incident response procedures
- Communicate security awareness information
- Contact a supplier
- Escalate to management
23. Threat Intelligence Action Register
| ID | Threat | Action | Owner | Priority | Due Date | Status | Evidence |
|---|---|---|---|---|---|---|---|
| TI-A01 | Cloud credential attack | Review privileged IAM access | Cloud Lead | High | [Date] | Open | IAM review |
| TI-A02 | Critical application vulnerability | Upgrade dependency | Engineering | Critical | [Date] | In Progress | Deployment record |
| TI-A03 | Phishing campaign | Employee awareness alert | IT / HR | Medium | [Date] | Closed | Communication |
24. AWS SaaS Example
Intelligence Received
A trusted security source reports active exploitation of a vulnerability affecting a software component.
Collection
The Security Lead records the advisory and source information.
Validation
Engineering confirms the advisory against the software vendor’s official information.
Analysis
The organization determines:
- The affected component is used.
- It is deployed in production.
- The application is internet-facing.
- Customer information is processed.
- Exploitation has been reported.
Action
Engineering upgrades the component and deploys the updated version.
Security performs a follow-up scan.
Evidence
The organization retains:
- Threat intelligence report
- Vendor advisory
- Applicability assessment
- Vulnerability ticket
- Code/deployment record
- Scan result
- Risk assessment, where applicable
Outcome
The intelligence has been converted into a measurable security action.
25. Threat Intelligence Sharing
Where appropriate and authorized, the organization may share relevant threat information with:
- Customers
- Suppliers
- Security communities
- Industry groups
- Government or cybersecurity authorities
- Managed security providers
Information sharing should consider:
- Confidentiality
- Privacy
- Contractual restrictions
- Legal requirements
- Sensitivity of security information
The organization should not disclose confidential customer or security information without appropriate authorization.
26. Roles and Responsibilities
Top Management
- Support appropriate threat intelligence activities.
- Review significant threats affecting business objectives.
- Provide resources where required.
ISMS / Security Manager
- Define intelligence requirements.
- Maintain relevant sources.
- Coordinate collection and analysis.
- Assess organizational relevance.
- Coordinate actions.
- Maintain records.
IT / Cloud / Engineering
- Assess technical exposure.
- Validate affected systems.
- Implement remediation.
- Provide evidence.
Incident Response Team
- Investigate intelligence indicating potential compromise.
- Conduct containment and response where required.
- Preserve relevant evidence.
Risk Owners
- Assess changes to assigned risks.
- Determine appropriate risk treatment.
Compliance / Privacy / Legal
- Assess regulatory, contractual, and privacy implications where applicable.
27. Threat Intelligence Metrics
The organization may monitor:
- Number of intelligence items received
- Number assessed
- Number determined relevant
- Number requiring action
- Number of critical/high intelligence items
- Time to assess critical intelligence
- Number of vulnerabilities prioritized using intelligence
- Number of risks updated
- Number of incidents identified through intelligence
- Percentage of critical actions completed within target
Metrics should be appropriate to the organization’s size and security maturity.
28. Records and Evidence
Records may include:
- Threat intelligence reports
- Security advisories
- Intelligence feeds
- Analysis records
- Threat Intelligence Register
- Technical indicators
- Applicability assessments
- Vulnerability tickets
- Risk assessments
- Incident records
- Remediation records
- Communication records
- Management reports
Records should be retained according to the organization’s documented information retention requirements.
29. Review and Continual Improvement
The process should be periodically reviewed to determine:
- Are the intelligence sources still relevant?
- Are important threats being identified?
- Is the volume of information manageable?
- Is intelligence reaching the correct teams?
- Are intelligence items being converted into actions?
- Are vulnerability priorities being improved?
- Are security controls being updated?
- Are intelligence-related incidents being captured?
- Are additional sources required?
Lessons learned from incidents and security events should be incorporated into future intelligence requirements.
30. 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 security information.
Threat Assessment Template
Provides a structured assessment of a specific threat.
Security Risk Assessment
Determines the organizational risk resulting from the threat.
Risk Register
Records material information security risks.
Vulnerability Management Procedure
Manages vulnerabilities identified through intelligence.
Incident Management Procedure
Handles actual or suspected security incidents.
Security Awareness Procedure
Uses relevant threat information to improve employee awareness.
Supplier Security Management
Addresses threats affecting critical suppliers.
Management Review
Provides management visibility of significant threat developments.
31. Startup-Friendly Implementation
A startup does not necessarily need an expensive threat intelligence platform.
A practical approach is:
Identify Critical Assets
↓
Define Intelligence Requirements
↓
Select Reliable Sources
↓
Monitor Relevant Intelligence
↓
Validate Important Information
↓
Assess Organizational Exposure
↓
Link to Vulnerability / Risk / Incident Process
↓
Take Action
↓
Verify
↓
Retain Evidence
↓
Review and Improve
For a small AWS SaaS organization, existing security advisories, cloud-provider notifications, software-vendor alerts, vulnerability information, security monitoring, and relevant industry sources may provide a sufficient starting point.
A dedicated threat intelligence platform can be introduced when the organization’s threat volume, monitoring requirements, or security operations justify it.
32. Quick Audit Checklist
| Audit Question | Evidence |
|---|---|
| Are threat intelligence requirements defined? | Intelligence requirements |
| Are relevant sources identified? | Source Register |
| Are sources monitored? | Subscriptions / alerts |
| Is source reliability considered? | Source assessment |
| Is intelligence validated? | Analysis records |
| Is organizational relevance assessed? | Applicability assessment |
| Are threats analysed? | Threat assessment |
| Are vulnerabilities linked where applicable? | Vulnerability records |
| Are risks updated where necessary? | Risk Register |
| Is actionable intelligence communicated? | Communication records |
| Are actions assigned and tracked? | Action Register |
| Are actual incidents escalated? | Incident records |
| Is evidence retained? | ISMS records |
| Are intelligence sources periodically reviewed? | Review records |
| Is the process improved using lessons learned? | Improvement records |
33. Final Principle
Threat intelligence should not become a collection of security alerts that nobody acts upon.
The objective is to create a practical intelligence cycle:
Direction → Collect → Validate → Analyse → Contextualize → Prioritize → Act → Verify → Learn → Improve
The key question is:
“What does this threat information mean for our organization, and what should we do about it?”