ISO 27001 Annex A 5.7 focuses on collecting and analyzing information about information security threats to help the organization take appropriate preventive and corrective actions.
The purpose is to help the organization understand:
- Current and emerging cybersecurity threats
- Threat actors and their techniques
- Vulnerabilities that may affect the organization
- Indicators of compromise
- Industry-specific threats
- Relevant attack patterns
- Changes in the threat landscape
- Potential impact on the organization’s systems and information
Simple explanation
A.5.7 means an organization should collect, analyze, and use relevant threat information to understand what could attack the organization and take appropriate action before or when those threats become relevant.
Threat intelligence should not simply be a collection of security alerts.
The organization should be able to determine:
What is the threat? → Does it affect us? → How serious is it? → What should we do?
Why is A.5.7 important?
Cybersecurity threats change continuously.
Attackers develop new techniques, vulnerabilities are discovered, malware evolves, and new technologies create new attack opportunities.
An organization that only reacts after an incident may have limited time to protect itself.
Threat intelligence can help an organization:
- Identify emerging threats
- Understand likely attack techniques
- Prioritize vulnerabilities
- Improve security monitoring
- Strengthen preventive controls
- Improve incident response
- Update risk assessments
- Protect critical systems
- Improve security awareness
- Make better cybersecurity decisions
For startups, threat intelligence can help a small security team focus its limited resources on threats that are actually relevant to the business.
What does A.5.7 require?
The organization should establish a process for obtaining and analyzing information about information security threats.
Threat intelligence can come from multiple sources, including:
- Government cybersecurity advisories
- CERT/CSIRT organizations
- Security vendors
- Cloud providers
- Security research organizations
- Industry groups
- Threat intelligence platforms
- Vulnerability databases
- Security communities
- Incident reports
- Internal security monitoring
- Information-sharing communities
The organization should determine which sources are relevant to its:
- Industry
- Technology
- Geographic locations
- Business model
- Threat profile
- Regulatory requirements
- Customer requirements
- Risk environment
Types of Threat Intelligence
Threat intelligence can be considered at different levels.
1. Strategic Threat Intelligence
Strategic intelligence provides information about the broader threat landscape.
Examples:
- Major cybersecurity trends
- Industry-specific threats
- Emerging threat actors
- Ransomware trends
- Changes in regulatory or geopolitical risks
- Major changes in the threat landscape
Example
A financial technology company may monitor trends involving:
- Banking fraud
- Account takeover
- Ransomware
- API attacks
- Payment fraud
- Supply-chain attacks
Management can use this information when reviewing organizational risks and security priorities.
2. Tactical Threat Intelligence
Tactical intelligence focuses on how attackers operate.
It may include information about:
- Attack techniques
- Tactics
- Procedures
- Exploitation methods
- Phishing techniques
- Credential theft
- Persistence techniques
- Lateral movement
This information can help security teams improve controls and detection capabilities.
3. Operational Threat Intelligence
Operational intelligence focuses on specific ongoing or potential attacks.
Examples include:
- Current campaigns
- Active threat actors
- Attack methods being observed
- Targeted industries
- Exploitation campaigns
This can help security teams understand whether a current campaign could affect their organization.
4. Technical Threat Intelligence
Technical intelligence contains technical indicators and security information.
Examples:
- Malicious IP addresses
- Malicious domains
- File hashes
- URLs
- Malware signatures
- Indicators of compromise (IOCs)
- Vulnerability information
Technical intelligence can potentially be used by security tools such as:
- SIEM
- EDR
- Firewalls
- IDS/IPS
- Email security systems
- Vulnerability management platforms
Activities required to implement A.5.7
1. Identify relevant threat intelligence sources
The organization should identify sources that provide information relevant to its environment.
Examples:
| Source | Information |
|---|---|
| Government security advisories | National and sector threats |
| CERT/CSIRT | Vulnerabilities and incidents |
| Cloud providers | Cloud security threats |
| Security vendors | Malware and attack intelligence |
| Vulnerability databases | Vulnerabilities and CVEs |
| Industry groups | Sector-specific threats |
| Security researchers | Emerging vulnerabilities |
| Internal monitoring | Organization-specific threats |
The organization does not need to monitor every source available on the internet.
Relevance is more important than quantity.
2. Define what threats are relevant
Not every cybersecurity threat is equally important to every organization.
The organization should consider:
- Critical assets
- Technologies used
- Data processed
- Customer requirements
- Industry
- Geography
- Business model
- Existing vulnerabilities
- Threat history
Example
A SaaS company using AWS, GitHub, Kubernetes and PostgreSQL may prioritize:
- Cloud attacks
- Credential theft
- API attacks
- Supply-chain attacks
- Container vulnerabilities
- Web application vulnerabilities
- Identity attacks
- Ransomware
A manufacturing organization may have a different threat profile.
3. Collect threat intelligence
The organization should establish appropriate methods for obtaining relevant threat information.
This could include:
- Security advisories
- Threat intelligence feeds
- Vulnerability notifications
- Security newsletters
- Vendor alerts
- Industry communications
- Internal security monitoring
- SIEM alerts
- EDR alerts
- Incident reports
- Security research
For smaller organizations, this does not necessarily require an expensive threat intelligence platform.
A combination of reliable security advisories, vendor notifications and internal monitoring may be sufficient depending on the organization’s risk.
4. Analyze the information
Simply receiving threat intelligence is not enough.
The organization should determine:
Is this threat relevant to us?
For example:
A critical vulnerability is announced for a software component.
The security team should determine:
- Do we use this software?
- Which versions do we use?
- Are affected systems internet-facing?
- Is the vulnerability exploitable in our environment?
- Is there evidence of active exploitation?
- What data or systems could be affected?
- What mitigation is available?
- What action should we take?
5. Assess the potential impact
Relevant threats should be evaluated based on potential impact.
Consider:
- Confidentiality
- Integrity
- Availability
- Customer data
- Personal information
- Financial systems
- Critical business services
- Regulatory obligations
- Reputation
- Business continuity
The threat information can then be incorporated into the organization’s risk management process where appropriate.
6. Take appropriate action
Where threat intelligence identifies a relevant risk, the organization should take appropriate action.
Possible actions include:
- Applying security patches
- Blocking malicious IP addresses
- Blocking malicious domains
- Updating firewall rules
- Updating endpoint controls
- Changing configurations
- Increasing monitoring
- Reviewing access controls
- Updating detection rules
- Conducting vulnerability assessments
- Updating risk assessments
- Improving security awareness
- Conducting incident response activities
The appropriate response depends on the organization’s risk and circumstances.
7. Record the results
The organization should maintain reasonable evidence showing how threat intelligence is used.
Examples:
- Threat intelligence register
- Threat reports
- Security advisories
- Vulnerability tickets
- Risk assessments
- Security monitoring records
- Incident records
- Patch records
- Remediation tickets
- Management review records
The objective is not to create unnecessary documentation.
The objective is to demonstrate that threat intelligence is received, evaluated and used where relevant.
Startup Example
Consider a SaaS startup serving customers in the United States.
The company uses:
- AWS
- GitHub
- Kubernetes
- PostgreSQL
- Microsoft 365
- Third-party SaaS applications
The startup identifies several relevant threat intelligence sources.
Step 1 – Receive information
The security team receives an alert about a critical vulnerability affecting a software component.
↓
Step 2 – Determine applicability
The team checks whether the vulnerable component is used.
↓
Step 3 – Identify affected systems
The team identifies systems using the affected version.
↓
Step 4 – Assess risk
The team determines whether the vulnerable systems are:
- Internet-facing
- Business-critical
- Processing sensitive information
↓
Step 5 – Take action
The company may:
- Apply the patch
- Upgrade the component
- Apply mitigation
- Increase monitoring
↓
Step 6 – Validate
The team verifies that the vulnerability has been addressed.
↓
Step 7 – Record
The vulnerability and remediation evidence are retained.
This demonstrates the practical connection between:
Threat Intelligence → Risk Assessment → Vulnerability Management → Security Action
Startup-Focused Quick Summary
Do startups need an expensive Threat Intelligence Platform?
Not necessarily.
ISO 27001 does not mean that every startup must purchase a commercial threat intelligence platform.
The organization should implement an approach that is appropriate to its size, risk, technology and business environment.
A simple startup approach
A startup can begin with:
- Identify 5–10 relevant threat information sources.
- Subscribe to important security advisories.
- Assign a security owner.
- Monitor relevant threats periodically.
- Determine whether threats affect the organization.
- Assess the risk.
- Take appropriate action.
- Maintain evidence.
Simple rule
Don’t collect threat feeds just to show an auditor. Collect intelligence that helps you make better security decisions.
Example Threat Intelligence Register
| Threat Source | Threat Area | Owner | Frequency | Relevant Threat | Risk | Action |
|---|---|---|---|---|---|---|
| Government Security Advisory | Cybersecurity | Security Lead | Weekly | Yes/No | High/Medium/Low | If applicable |
| Cloud Provider Alerts | Cloud | Cloud Lead | Daily | Yes/No | High/Medium/Low | If applicable |
| Vulnerability Database | Vulnerabilities | Security Team | Daily | Yes/No | High/Medium/Low | Patch/Mitigate |
| Security Vendor | Malware | Security Team | Weekly | Yes/No | High/Medium/Low | If applicable |
| Industry Community | Industry Threats | Compliance | Monthly | Yes/No | High/Medium/Low | If applicable |
The register should be customized according to the organization’s actual technology and risk profile.
Threat Intelligence Lifecycle
A practical A.5.7 process can be represented as:
Identify Sources
↓
Collect Intelligence
↓
Validate Information
↓
Analyze Relevance
↓
Assess Risk
↓
Prioritize
↓
Take Action
↓
Monitor Results
↓
Record Evidence
↓
Review Intelligence Sources
A.5.7 Audit Evidence
An auditor may look for evidence such as:
Threat intelligence sources
- Threat intelligence subscriptions
- Security advisories
- CERT/CSIRT communications
- Vendor security notifications
- Industry security information
- Vulnerability databases
Analysis evidence
- Threat assessments
- Security review records
- Threat intelligence reports
- Vulnerability assessments
- Risk assessment updates
Action evidence
- Patch tickets
- Vulnerability remediation records
- Firewall changes
- SIEM/EDR rules
- Incident response records
- Security configuration changes
Management evidence
- Security review meetings
- Risk committee records
- Management reports
- Security metrics
- Escalation records
A.5.7 Audit Checklist
| Audit Question | Evidence |
|---|---|
| Has the organization identified relevant threat intelligence sources? | Threat Intelligence Register |
| Are the sources relevant to the organization’s risks? | Risk Assessment |
| Is threat information collected periodically? | Advisories / Feeds / Reports |
| Is threat information analyzed? | Threat Assessment |
| Does the organization determine whether threats are relevant? | Analysis Records |
| Are significant threats incorporated into risk management? | Risk Register |
| Are appropriate actions taken? | Remediation Tickets |
| Are vulnerabilities identified through intelligence addressed? | Patch / Vulnerability Records |
| Are threat intelligence sources periodically reviewed? | Review Records |
| Can the organization demonstrate how intelligence improves security decisions? | Reports / Actions / Meeting Records |
Common Mistakes
1. Treating threat intelligence as a collection of feeds
Having multiple threat feeds does not automatically demonstrate effective threat intelligence.
The organization needs to analyze and use relevant information.
2. Collecting information without ownership
If nobody is responsible for reviewing threat information, important alerts may be missed.
Assign a clear owner.
3. Treating every threat as an emergency
Not every threat reported globally affects your organization.
The organization should determine:
Does this threat actually apply to us?
4. No connection to vulnerability management
Threat intelligence should be connected where appropriate to:
- Vulnerability management
- Risk management
- Security monitoring
- Incident management
5. No evidence of action
An organization may say:
“We monitor cybersecurity threats.”
An auditor may ask:
“Show me how you use that information.”
Maintain reasonable records of important assessments and resulting actions.
6. Buying expensive tools unnecessarily
A startup should not assume that compliance requires an expensive commercial threat intelligence platform.
The solution should be proportionate to the organization’s:
Risk + Size + Technology + Business Environment
Practical Implementation Model
A simple A.5.7 implementation model is:
Identify → Collect → Validate → Analyze → Assess → Act → Monitor → Record → Review
The process should connect external threat information with the organization’s actual security environment.
Policy vs. Process vs. Evidence
| Element | Example |
|---|---|
| Policy | The organization shall obtain and analyze relevant information about information security threats. |
| Process | Security personnel monitor selected sources, evaluate relevant threats and initiate appropriate actions. |
| Evidence | Threat reports, advisories, vulnerability tickets, risk assessments, remediation records and security review records. |
The objective is not to create a large collection of threat reports.
The objective is to ensure that relevant threat information reaches the right people and results in appropriate security decisions.
Useful Resources
Recommended documents
- Threat Intelligence Procedure – [Insert Draft Document Link]
- Threat Intelligence Register – [Insert Draft Document Link]
- Threat Assessment Template – [Insert Draft Document Link]
- Vulnerability Management Procedure – [Insert Draft Document Link]
- Security Risk Assessment Template – [Insert Draft Document Link]
- Incident Management Procedure – [Insert Draft Document Link]
Related ISO 27001 controls
A.5.7 can work closely with:
- A.5.6 – Contact with special interest groups
- A.5.24 – Information security incident management planning and preparation
- A.5.25 – Assessment and decision on information security events
- A.5.26 – Response to information security incidents
- A.5.27 – Learning from information security incidents
- A.8.8 – Management of technical vulnerabilities
- A.8.16 – Monitoring activities
Final Takeaway
ISO 27001 Annex A 5.7 is about turning information about cybersecurity threats into useful security decisions.
A practical organization should be able to answer:
Where do we obtain threat information?
Which threats are relevant to us?
Who analyzes them?
How do we assess their impact?
What action do we take?
How do we know the action was effective?
For startups, the approach can remain simple:
Identify → Collect → Analyze → Assess → Act → Record → Review
The objective is not to collect the largest number of threat feeds.
It is to ensure that relevant threat intelligence helps the organization identify risks earlier, prioritize security actions, and improve its overall security posture.